Javascript in PRADO, Questions and Answers
How do I include the Javascript libraries distributed with Prado?
-The javascript libraries distributed with Prado can be found in the +
The javascript libraries distributed with Prado can be found in the framework/Web/Javascripts/source directory. The packages.php file in that directory defines a list of available package names available to be loaded. They can be loaded as follows. @@ -36,7 +36,7 @@ and its dependencies will be automatically included on the page.
See TClientScript for options of adding your custom Javascript code to the page.
-Publishing Javascript Libraries as Assets
+Publishing Javascript Libraries as Assets
Use TClientScriptLoader to publish and combine multiple existing javascript files (e.g. javascript libraries distributed with Prado or otherwise) as packages.
For greater control on what and when to publish, use the diff --git a/demos/quickstart/protected/pages/Configurations/Templates1.page b/demos/quickstart/protected/pages/Configurations/Templates1.page index 93f5662f..1252f8a7 100644 --- a/demos/quickstart/protected/pages/Configurations/Templates1.page +++ b/demos/quickstart/protected/pages/Configurations/Templates1.page @@ -41,7 +41,7 @@ To facilitate initializing properties with big trunk of data, the following prop PropertyValue </prop:PropertyName> -+
Since version 3.1.0, the property initialization tag can also be used to initialize a set of subproperties who share the same parent property. For example, the following is equivalent to HeaderStyle.BackColor="black" and HeaderStyle.ForeColor="red".
Prado Validation Controls
+Prado Validation Controls
TRequiredFieldValidator
@@ -160,7 +160,7 @@ The summary can be displayed as a list, a bulleted list, or a single paragraph b
Interacting the Validators
-Resetting or Clearing of Validators
+Resetting or Clearing of Validators
Validators can be reset on the client-side using javascript by calling the Prado.Validation.reset(groupID) where groupID is the validator diff --git a/demos/quickstart/protected/pages/Database/ActiveRecord.page b/demos/quickstart/protected/pages/Database/ActiveRecord.page index 1e3c69c5..87d83740 100644 --- a/demos/quickstart/protected/pages/Database/ActiveRecord.page +++ b/demos/quickstart/protected/pages/Database/ActiveRecord.page @@ -3,15 +3,16 @@
Active Record
Active Records are objects that wrap a row in a database table or view, - encapsulates the database access and adds domain logic on that data. - The basics of an Active Record is a business object class, e.g., a + encapsulate the database access and add domain logic on that data. + The basics of an Active Record are business classes, e.g., a Products class, that match very closely the record structure of an underlying database table. Each Active Record will be responsible for saving and loading data to and from the database.
When to Use It
@@ -32,7 +33,7 @@ business object and how these objects are stored. Prado provides a complimentary choice between Active Record and SqlMap Data Mapper. - A SqlMap Data Mapper can be used to load Active Record objects, in turn, these + A SqlMap Data Mapper can be used to load Active Record objects, in turn; these Active Record objects can be used to update the database. The "relationship" between Active Records and SqlMap is illustrated in the following diagram. More details regarding the SqlMap Data Mapper can be found in @@ -41,15 +42,15 @@- The Active Record class has methods that do the following: + The Active Record class has functionality to perform the following tasks.
-
-
- Construct an instance of the Active Record from a SQL result set row. -
- Construct a new instance for later insertion into the table. +
- Create, Retrieve, Update and Delete records.
- Finder methods to wrap commonly used SQL queries and return Active Record objects. -
- Update existing records and insert new records into the database. +
- Fetch relationships (related foreign objects) such as "has many", "has one", "belongs to" and "has many" via association table. +
- Lazy loading of relationships.
Database Supported
+Database Supported
The Active Record implementation utilizes the Prado DAO classes for data access. The current Active Record implementation supports the following database. @@ -60,12 +61,12 @@ The current Active Record implementation supports the following database.
Support for other databases can be provided when there are sufficient demand.
+Support for other databases can be provided when there are sufficient demands.
Defining an Active Record
Let us
- consider the following "users" table that contains two columns named "username" and "email",
- where "username" is also the primary key.
+ consider the following "users" table that contains two columns named "username" and "email",
+ where "username" is also the primary key.
Next we define our Active Record class that corresponds to the "users" table. +
Next we define our Active Record class that corresponds to the "users" table.
Each property of the UserRecord class must correspond to a - column with the same name in the "users" table. The class constant +
Each column of the "users" table must have corresponding + property of the same name as the column name in the UserRecord class. + Of course, you also define additional member variables or properties that does not exist in the table structure. + The class constant TABLE is optional when the class name is the same as the table name in the database, otherwise TABLE must specify the table name that corresponds to your Active Record class. @@ -123,6 +126,9 @@ class UserRecord extends TActiveRecord { } }
More details regarding TComponent can be found in the Components documentation. +Later we shall use the getter/setters to allow for lazy loading of relationship objects. +
The static method finder() returns an UserRecord instance that can be used to load records from the database. The loading of records - using the finer methods is discuss a little later. The TActiveRecord::finder() - static method takes the name of the current Active Record class as parameter. + using the finer methods is discussed a little later. The TActiveRecord::finder() + static method takes the name of an Active Record class as parameter.
Setting up a database connection
A default database connection for Active Record can be set as follows. See Establishing Database Connection for - futher details regarding creation of database connection in general. + further details regarding creation of database connection in general. +
Alternatively, you can create a base class and override the getDbConnection() +method to return a database connection. This is a simple way to permit multiple +connections and multiple databases. The following code demonstrates defining +the database connection in a base class (not need to set the DB connection anywhere else).
+Using application.xml within the Prado Framework
+The default database connection can also be configured using a <module> tag in the application.xml @@ -167,7 +204,7 @@ TActiveRecordManager::getInstance()->setDbConnection($conn); The EnableCache attribute when set to "true" will cache the table meta data, that is, the table columns names, indexes and constraints are saved in the cache and reused. You must clear or disable the cache if you - wish to see chanages made to your table definitions. A cache + wish to see changes made to your table definitions. A cache module must also be defined for the cache to function.
Loading data from the database
The TActiveRecord class provides many convenient methods to find
- records from the database. The simplest is finding records by matching primary keys.
+ records from the database. The simplest is finding one record by matching a primary key or a
+ composite key (primary keys that consists of multiple columns).
See the
findByPk()
-Finds one record using only the primary key or composite primary keys. + +
findByPk()
+Finds one record using only a primary key or a composite key.
findAllByPks()
-Finds multiple records using a list of primary keys or composite primary keys. -The following are equivalent for scalar primary keys (primary key consisting of only one column/field). +
Finds multiple records using a list of primary keys or composite keys. +The following are equivalent for primary keys (primary key consisting of only one column/field). +
find()
@@ -270,13 +315,24 @@ $criteria->Limit = 10; $criteria->Offset = 20; +findAll()
Same as find() but returns an array of objects.
findBy*() and findAllBy*()
-Dynamic find method using parts of method name as search criteria. -Method names starting with findBy return 1 record only. -Method names starting with findAllBy return an array of records. +
Dynamic find method using parts of the method name as search criteria. +Method names starting with findBy return 1 record only +and method names starting with findAllBy return an array of records. The condition is taken as part of the method name after findBy or findAllBy. The following blocks of code are equivalent: @@ -298,14 +354,25 @@ $finder->findAll('Age = ?', $age);
findBySql()
-Finds records using full SQL, returns corresponding array of record objects.
- +findBySql() and findAllBySql()
+Finds records using full SQL where findBySql()
+return an Active Record and findAllBySql()returns an array of record objects.
+For each column returned, the corresponding Active Record class must define a member variable or
+property for each corresponding column name.
+
count()
-Find the number of matchings records.
+Find the number of matchings records, accepts same parameters as the findAll() method.
Inserting and updating records
@@ -327,7 +394,7 @@ The objects are update with the primary key of those the tables that contains definitions that automatically creates a primary key for the newly insert records. For example, if you insert a new record into a MySQL table that has columns defined with "autoincrement", the Active Record objects will be updated with the new -incremented values. +incremented value.
To update a record in the database, just change one or more properties of @@ -341,7 +408,7 @@ $user->save(); //update it.
-+
Active Record objects have a simple life-cycle illustrated in the following diagram.
Deleting existing records
To delete an existing record that is already loaded, just call the delete() method. You can also delete records in the database by primary keys without - loading any records using the deleteByPk() method. - For example, to delete one or records with tables having a scalar primary key. + loading any records using the deleteByPk() method (and equivalently the deleteAllByPks() method). + For example, to delete one or records with tables using one or more primary keys.
-For composite primary keys (determined automatically from the table definitions): +For composite keys (determined automatically from the table definitions):
deleteAll() and deleteBy*()
To delete by a criteria, use deleteAll($criteria) and deleteBy*() -with similar synatx to findAll($criteria) and findAllBy*() as +with similar syntax to findAll($criteria) and findAllBy*() as described above.
Transactions
-All Active Record objects contains the property DbConnection +
All Active Record objects contain the property DbConnection
that can be used to obtain a transaction object.
Events
++The TActiveRecord offers two events, OnCreateCommand and OnExecuteCommand. +
+ +The OnCreateCommand event is raised when a command is prepared and +parameter binding is completed. The parameter object is TDataGatewayEventParameter of which the +Command property can be inspected to obtain the SQL query to be executed. +
+ ++The OnExecuteCommand event is raised when a command is executed and the +result from the database was returned. The parameter object is TDataGatewayResultEventParameter +of which the Result property contains the data return from the database. +The data returned can be changed by setting the Result property. +
+ +Logging Example
+Using the OnExecuteCommand we can attach an event handler to log +the entire SQL query executed for a given TActiveRecord class or instance. For example, we define +a base class and override either the getDbConnection() or the constructor. +
+ +Active Record Relationships
+The Prado Active Record implementation supports the foreign key mappings for database -that supports foreign key contraints. For ActiveRecord relationships to function the -underlying database must support foreign key constraints (e.g. MySQL with InnoDB). +that supports foreign key constraints. For Active Record relationships to function the +underlying database must support foreign key constraints (e.g. MySQL using InnoDB).
-+
In the following sections we shall consider the following table relationships between Teams, Players, Skills and Profiles.
-
+The goal is to obtain object models that represents to some degree the entity +
The goal is to obtain object models that represent to some degree the entity relationships in the above figure.
-
+There is a mismatch between relationships with objects and table relationships. @@ -449,14 +567,33 @@ structure between objects and tables. The approach taken in the Prado Active Rec design is to use the table foreign key constraints to derive object relationships. This implies that the underlying database must support foreign key constraints.
-Foreign Key Mapping
+Foreign Key Mapping
The entity relationship between the Teams and Players table is what is known as an 1-M relationship. That is, one Team may contain 0 or more Players. In terms of -object relationships, we say that the Team object has many Player objects. +object relationships, we say that a TeamRecord object has many PlayerRecord objects. (Notice the reversal of the reversal of the direction of relationships between tables and objects.) -
-
Has Many Relationship
-+
+
Has Many Relationship
+We model the Team object as the following Active Record classes.
+
The static $RELATIONS property of TeamRecord defines that the -property $players has many PlayerRecords. Multiple relationships +property $players has many PlayerRecords. Multiple relationships is permitted by defining each relationship with an entry in the $RELATIONS array where array key for the entry corresponds to the property name. In array(self::HAS_MANY, 'PlayerRecord'), the first element defines the -relationship type, the valid types are self::HAS_MANY, -self::HAS_ONE and self::BELONGS_TO. +relationship type, the valid types are self::HAS_MANY, +self::HAS_ONE and self::BELONGS_TO. The second element is a string 'PlayerRecord' that corresponds to the class name of the PlayerRecord class.
-+
The foreign key constraint of the Players table is used to determine the corresponding Teams table's corresponding key names. This is done automatically handled in Active Record by inspecting the Players and Teams table definitions.
The has many relationship is not fetched automatically when you use any of the Active Record finder methods. +
The "has many" relationship is not fetched automatically when you use any of the Active Record finder methods. You will need to explicitly fetch the related objects as follows. In the code below, both lines are equivalent and the method names are case insensitive.
+ +
The method with_xxx() (where xxx is the relationship property -name, in this case, players) fetchs the corresponding PlayerRecords using +name, in this case, players) fetches the corresponding PlayerRecords using a second query (not by using a join). The with_xxx() accepts the same -arguments as other finder methods of TActiveRecord, e.g. with_players('age < ?', 35). +arguments as other finder methods of TActiveRecord, e.g. with_players('age = ?', 35).
Belongs To Relationship
- +Belongs To Relationship
+The "has many" relationship in the above section defines a collection of foreign +objects. In particular, we have that a TeamRecord has many (zero or more) +PlayerRecord objects. We can also add a back pointer by adding a property +in the PlayerRecord class that links back to the TeamRecord object, +effectively making the association bidirectional. +We say that the $team property in PlayerRecord class belongs to a TeamRecord object. +The following code defines the complete PlayerRecord class with 3 relationships. +
+The static $RELATIONS property of PlayerRecord defines that the +property $team belongs to a TeamRecord. +The $RELATIONS array also defines two other relationships that we +shall examine in later sections below. +In array(self::BELONGS_TO, 'TeamRecord'), the first element defines the +relationship type, in this case self::BELONGS_TO and +the second element is a string 'TeamRecord' that corresponds to the +class name of the TeamRecord class. +A player object with the corresponding team object may be fetched as follows. +
++ The method with_xxx() (where xxx is the relationship property + name, in this case, team) fetches the corresponding TeamRecords using + a second query (not by using a join). The with_xxx() accepts the same +arguments as other finder methods of TActiveRecord, e.g. +with_team('location = ?', 'Madrid'). +
-Has One Relationship
+The "belongs to" relationship of ProfileRecord class is defined similarly.
In essence, there exists a "belongs to" relationship for objects corresponding to +entities that has column which are foreign keys. In particular, we see that +the Profiles table has a foreign key constraint on the column player_id +that relates to the Players table's player_id column. Thus, the ProfileRecord +object has a property ($player) that belongs to a PlayerRecord object. +Similarly, the Players table has a foreign key constraint on the column team_name that relates to the +Teams table's name column. +Thus, the PlayerRecord object has a property ($team) that belongs to a +TeamRecord object. +
+ +Has One Relationship
+The entity relationship between Players and Profiles is one to one. That is, +each PlayerRecord object has one ProfileRecord object (may be none or null). +A has one relationship is nearly identical to a has many relationship with the exception +that the related object is only one object (not a collection of objects). +
+ +Parent Child Relationships
+A parent child relationship can be defined using a combination of has many and belongs to +relationship that refers to the same class. The following example shows a parent children relationship between +"categories" and a "parent category". +
+ +Association Table Mapping
+Association Table Mapping
++Objects can handle multivalued fields quite easily by using collections as field values. +Relational databases don't have this feature and are constrained to single-valued fields only. +When you're mapping a one-to-many association you can handle this using has many relationships, +essentially using a foreign key for the single-valued end of the association. +But a many-to-many association can't do this because there is no single-valued end to +hold the foreign key. +
++The answer is the classic resolution that's been used by relational data people +for decades: create an extra table (an association table) to record the relationship. +The basic idea is using an association table to store the association. This table +has only the foreign key IDs for the two tables that are linked together, it has one +row for each pair of associated objects. +
++The association table has no corresponding in-memory object and its primary key is the +compound of the two primary keys of the tables that are associated. +In simple terms, to load data from the association table you perform two queries (in general, it may also be achieved using one query consisting of joins). +Consider loading the SkillRecord collection for a list PlayerRecord objects. +In this case, you do queries in two stages. +The first stage queries the Players table to find all the rows of the players you want. +The second stage finds the SkillRecord object for the related player ID for each row +in the Player_Skills association table using an inner join. +
+ +The Prado Active Record design implements the two stage approach. For the +Players-Skills M-N (many-to-many) entity relationship, we need +to define a has many relationship in the PlayerRecord class and +in addition define a has many relationship in the SkillRecord class as well. +The following sample code defines the complete SkillRecord class with a +many-to-many relationship with the PlayerRecord class. (See the PlayerRecord +class definition above to the corresponding many-to-many relationship with the SkillRecord class.) +
+The static $RELATIONS property of SkillRecord defines that the +property $players has many PlayerRecords via an association table 'Player_Skills'. +In array(self::HAS_MANY, 'PlayerRecord', 'Player_Skills'), the first element defines the +relationship type, in this case self::HAS_MANY, +the second element is a string 'PlayerRecord' that corresponds to the +class name of the PlayerRecord class, and the third element is the name +of the association table name. +
++A list of player objects with the corresponding collection of skill objects may be fetched as follows. +
++The method with_xxx() (where xxx is the relationship property +name, in this case, Skill) fetches the corresponding SkillRecords using +a second query (not by using a join). The with_xxx() accepts the same +arguments as other finder methods of TActiveRecord. +
+ +Self Referenced Association Tables
+
+For self referenced association tables, that is, the association points to the same
+table. For example, consider the items table with M-N related
+item via the related_items association table. The syntax in the following
+example is valid for a PostgreSQL database. For other database, consult their respective documentation for
+defining the foreign key constraints.
+
The association table name in third element of the relationship array may +contain the foreign table column names. The columns defined in the association +table must also be defined in the record class (e.g. the $related_item_id property +corresponds to the related_item_id column in the related_items table). +
+Adding/Removing/Updating Related Objects
+ +Related objects can be simply inserted/updated by first adding those related objects to +the current source object (i.e. the object currently been worked on) and then call +the save() method on the source object. The related object's references +and the association reference (if required) will be added and/or updated. +For example, to add two new players to the team (assuming that 'Team A' exists), we can simply do the following. +
+ ++Since the TeamRecord class contains a has many relationship with the PlayerRecord, +then saving a TeamRecord object will also update the corresponding foreign objects in $players array. +That is, the objects in $players are inserted/updated in the database and the +$team_name property of those objects will contain the foreign key value that corresponds to the $team object's primary key value. +
+ +To delete a particular foreign object (or any Active Record object), simply call +the object's delete() method. You may setup the database table's foreign key constraints such that +when deleting a particular data in the database it will delete the referenced data as well (it may also be achieved using database +triggers). E.g. such as having a "ON DELETE CASCADE" constraint. +Deleting foreign objects by either setting the property value to null or removing the object from an array will NOT +remove the corresponding data in the database. +
+ +To remove associations for the many-to-many relationships via an association table, an Active Record +that corresponds to the association table can be used. Then the association can be removed by calling the deleteByPk() method, for example: +
+Lazy Loading Related Objects
+Using the with_xxx() methods will load the relationship record on demand. Retrieving the +related record using lazy loading (that is, only when those related objects are accessed) can be +achieved by using a feature of the TComponent that provides accessor methods. In particular, +we define a pair of getter and setter methods where the getter method will retrieve the relationship +conditionally. The following example illustrates that the PlayerRecord can retrieve its +$skills foreign objects conditionally. +
+We first need to change the $skills=array() declaration to a private property +$_skills (notice the underscore) and set it to null instead. This allows us +to define the skills property using getter/setter methods +(see Components for details). The getSkills() +getter method for the skills property will lazy load the corresponding skills foreign record +when it is used as follows. Notice that we only do a lazy load when its $player_id is +not null (that is, when the record is already fetched from the database or player id was already set). +
+The setSkills() ensures that the skills property will always be a TList. +Using a TList allows us to set the elements of the skills property as if they were +arrays. E.g. $player->skills[] = new SkillRecord(). If array was used, a PHP error +will be thrown. +
+References
- Fowler et. al. Patterns of Enterprise Application Architecture,
diff --git a/demos/quickstart/protected/pages/Database/Scaffold.page b/demos/quickstart/protected/pages/Database/Scaffold.page
index 9afe4a3f..759e55d1 100644
--- a/demos/quickstart/protected/pages/Database/Scaffold.page
+++ b/demos/quickstart/protected/pages/Database/Scaffold.page
@@ -1,8 +1,8 @@
Active Record Scaffold Views
+Active Record Scaffold Views
Active Record classes can be used together with +
Active Record classes can be used together with
-The scaffold views are intended to assist in prototyping web application, +
The scaffold views are intended to assist in prototyping web application, they are not designed to be as customiziable as more complex components such as TDataGrid. The scaffold views provide the following builtin functionality: @@ -27,18 +27,18 @@ the following builtin functionality:
- Presents specialized controls such as date pickers.
Scaffold views are dependent on Active Records and currently supports +
Scaffold views are dependent on Active Records and currently supports the following databases: Mysql, Sqlite and Postgres SQL. Support for other databases can be considered when there are sufficient demand.
-Setting up a Scaffold View
-To use the scaffold view, we first define an Active Record +
Setting up a Scaffold View
+To use the scaffold view, we first define an Active Record class that represents a table or view in the database. Consider the following Active Record class that corresponds to the users table as defined in the Active Record quickstart page.
-The scaffold view classes are in the System.Data.ActiveRecord.Scaffold.* +
The scaffold view classes are in the System.Data.ActiveRecord.Scaffold.* namespace. This namespace can be "imported" in the Application Configuration @@ -59,11 +59,11 @@ simply set the RecordClass property value equal to an Active Record class name.
-The above code will list the current records in the users table. +
The above code will list the current records in the users table. Each record can be edited by clicking on the "edit" button and deleted by clicking on the "delete" button. A new record can be added by clicking on the "Add new record" button, enter some data (notice the automatic validation of required fields and data types), and click the "save" button. @@ -71,20 +71,20 @@ Specifying search terms in the search textbox to find particular records. Finall record list can be sorted for each column by changing the sorting column and order.
-The TScaffoldView is a template control composed of other scaffold controls. +
The TScaffoldView is a template control composed of other scaffold controls. The following properties gives access to these composite controls.
- ListView -- the TScaffoldListView displaying the record list.
- EditView -- the TScaffoldEditView that renders the inputs for editing and adding records.
- SearchControl -- the TScaffoldSearch responsible to the search user interface.
+
All these composite controls can be customized as we shall see below.
-TScaffoldListView
+TScaffoldListView
-A list of Active Records can be displayed using the TScaffoldListView +
A list of Active Records can be displayed using the TScaffoldListView with the following useful properties.
- Header -- a TRepeater @@ -96,7 +96,7 @@ the links and/or buttons that navigate to different pages in the Active Record d
- List -- a TRepeater that renders a row of Active Record data.
Custom rendering of the each Active Record can be achieved by specifying +
Custom rendering of the each Active Record can be achieved by specifying the ItemTemplate and/or AlternatingItemTemplate property of the List repeater. The TScaffoldListView will listen for two command events named "delete" and @@ -106,7 +106,7 @@ An "edit" command will push the record data to be edited by a The following example lists the usernames only with bold formatting.
-The SearchCondition property and +
The SearchCondition property and SearchParameters property (takes array values) can be specified to customize the records to be shown. The SearchCondition will be used as the Condition property of TActiveRecordCriteria and the SearchParameters property corresponds to Parameters property of TActiveRecordCriteria.
-TScaffoldEditView
-TScaffoldEditView
+Combining list + edit views
+Combining list + edit views
-Customizing the TScaffoldView
-Customizing the TScaffoldView
+Is PRADO Stable Enough?
-+
Is PRADO Stable Enough?
+Yes. PRADO was initially released in August 2004. Many test suites have been written and conducted frequently to ensure its quality. It has been used by thousands of developers and many Web applications have been developed based on it. Bugs and feature requests are managed through TRAC system and we have a great user community and development team to ensure all questions are answered in a timely fashion.
diff --git a/demos/quickstart/protected/pages/GettingStarted/Introduction.page b/demos/quickstart/protected/pages/GettingStarted/Introduction.page index f267d23d..3fd67d5d 100644 --- a/demos/quickstart/protected/pages/GettingStarted/Introduction.page +++ b/demos/quickstart/protected/pages/GettingStarted/Introduction.page @@ -4,14 +4,14 @@This Quickstart tutorial is provided to help you quickly start building your own Web applications based on PRADO version 3.x.
-+
If you are an existing PRADO 3.x user and would like to learn what enhancements are available for each new version, please check out the new features page. Otherwise, the following sections are helpful for newbies.