getChildren 126 getChildren Delegate Class Method Return to [[Delegate class methods]] [[toc]] The getChildren() method can be implemented in a table's delegate class to specify the logical "child" records of a given record which can be used when creating hierarchical applications. This method will effectively override the output of the Dataface_Record::getChildren() method for records of this table. ===Signature=== <code> function getChildren( Dataface_Record $record) : Dataface_Record[] </code> ===Parameters=== # '''$record''' - The Dataface_Record that is the subject of the query ===Returns=== This method should return an array of Dataface_Record objects that are considered to be children of the subject record. ===Examples=== <code> function getChildren($record){ return df_get_records('webpages', array( 'parent_id'=>'='.$record->val('webpage_id') ) ); } </code> ==See Also== * '''[[getParent]]''' - A Delegate class method to return the logical parent of a given record. getChildren Delegate class method en meta:class 127 meta:class relationships.ini file directive Return to [[relationships.ini file]] [[toc]] The ''meta:class'' directive allows you to ascribe special meaning to a relationship which Xataface can use in various parts of your application to provide enhanced capabilities. For example you can specify a relationship as a "parent" relationship, thereby using the relationship to obtain the "parent" of records of this table. This can be used to help build breadcrumbs. You can also specify a relationship as a "children" relationship which would treat records in the relationship as children of the current record. This can be used in conjunction with the [[list:type]]=treetable directive of the [[relationships.ini file]] to build a tree table that navigates all child records and subtrees. The Dataface_Record class contains some methods for retrieving the parent and children of records and these methods will take into account any settings you make here. ===Allowed Values=== {| class="listing listing2" |- ! Name ! Description ! Version |- | parent | Designates the relationship as a 'parent' relationship, meaning that the first record in this relationship will be treated as the parent of the current record. This setting can be overridden by the [[getParent]] method of the table delegate class if implemented. | 0.8 |- | children | Designates the relationship as a 'children' relationship meaning that records of the the relationship will be treated as a children. This setting can be overridden by the [[getChildren]] method of the table delegate class if implemented. | 0.8 |} ==See Also== # '''[[list:type]]''' - [[relationships.ini file]] directive to use a treetable for the related record list of a relationship. # '''[[getChildren]]''' - Delegate class method to explicitly define the Dataface_Record objects that are to be considered as child records of the current record. # '''[[getParent]]''' - Delegate class method to explicitly define the Dataface_Record object that is to be considered as the parent record of the current record. en list:type 128 list:type relationships.ini file directive Return to [[relationships.ini file]] [[toc]] The list:type directive allows you to override the default list that is used to display related records. As of Xataface 1.3 there is only one possible value that will have any effect on this directive: "treetable". Setting <code> list:type=treetable </code> will cause the related records to be displayed as an expandable/collapsible tree table as shown here: <nowiki><img src="http://media.weblite.ca/files/photos/Screen%20shot%202011-04-29%20at%2011.49.33%20AM.png?max_width=640"/></nowiki> ===Prerequisites=== The TreeTable component needs to be able to figure out the logical children of each record in order to know what to show when a row is expanded. You can use either the [[meta:class]] directive of the [[relationships.ini]] file to specify a relationship as a "children" relationship, or you can implement the [[getChildren]] method of the table delegate class to manually define a record's child elements. ==See Also== * [[getChildren]] * [[meta:class]] * [[getParent]] en fieldname__default 133 fieldname__default Delegate Class Method Return to [[Delegate class methods]] [[toc]] ===Synopsis=== Xataface allows you to pre-populate any particular field in a table by adding a fieldname__default method to the table's delegate class of the form: <code> function fieldname__default(){ return value; }</code> Returns the default value for the field fieldname. New record forms will be prepopulated with this value. ===Examples=== <code> function minimum_bid__default(){ return 100; }</code> <code> function mydatecol__default(){ return date('Y-m-d'); }</code> <code> function owner_id__default(){ $auth =& Dataface_AuthenticationTool::getInstance(); $user =& $auth->getLoggedInUser(); if ( isset($user) ) return $user->val('userid'); return null; }</code> ===See Also=== * [http://xataface.com/forum/viewtopic.php?t=5028 Pre-entered Data] (forum thread) - setting defaults field values on general fields using the fieldname__default delegate class function * [http://xataface.com/forum/viewtopic.php?t=4004 How to initialize a Date field to today's date?] (forum thread) - alternate methods to use specifically with a date/time field * [http://xataface.com/forum/viewtopic.php?t=3988 Setting default select setting from users table] (forum thread) - solution to populate the current user default, initialize, populate, pre-populate, delegate class default en after_action_activate 181 after_action_activate Delegate Class Method Return to [[Application Delegate Class]] [[toc]] The '''after_action_activate''' hook is a method that can be defined in the [[Application Delegate Class]] which is called after an account has been activated via the registration process. The full registration process goes as follows: # User fills in registration form. # An email is sent to the user with a link to activate their account. # User clicks on activation link. # User is taken back to the application and activation occurs, which consists of creating a new record in the '''users''' table. # The ''after_action_activate'' trigger is called. ===Since=== This hook has been available since Xataface Version 1.2 ===Example=== <code> /** * A trigger to send the user a confirmation email after their account has been activated. * @params array $params Associative array of passed parameters. Contains a single key 'record' * with the Dataface_Record object of the users table with the user that was activated. */ function after_action_activate(array $params){ $user = $params['record']; mail($user->val('email'), 'Your account is activated', 'Your account has been activated... etc..'); } </code> ===See Also=== * [[Application Delegate Class]] * [[registration_form]] - More information user registration forms. * [[beforeRegister]] - Trigger called before the user registration form is saved. * [[afterRegister]] - Trigger called after registration form is saved. * [[validateRegistrationForm]] - Validates the input into the registration form. * [[sendRegistrationActivationEmail]] - Overrides the sending of the registration activation email. * [[getRegistrationActivationEmailInfo]] - Overrides the activation email info. Returns an associative array of the email details (e.g. subject, to, headers, etc... * [[getRegistrationActivationEmailSubject]] - Returns the subject of the activation email. * [[getRegistrationActivationEmailMessage]] - Returns the message body for the activation email. * [[getRegistrationActivationEmailParameters]] - Returns the parameters for the actication email. * [[getRegistrationActivationEmailHeaders]] - Returns the headers for the activation email. Registration, activation, register, activate, users en field__fieldname 141 Defining Calculated Fields Return to [[Delegate class methods]] Xataface allows you to define calculated fields using the delegate class. These fields won't be visible in the UI by default, but they will be accessible to some modules (e.g. the HTML Reports Module) and they are always accessible to you via the API. E.g. If you define a calculated field named ''year'', you would be able to access this value using the regular Dataface_Record syntax: <code> $record->val('year'); </code> You could also define any number of filter methods and permissions on this field just as you can on regular fields. e.g. <code> function year__permissions($record){ // Return special permissions on the year field. } </code> or <code> function year__display($record){ // Override how the year is displayed in the UI. return $record->val('year').' A.D.'; } </code> ==How to Define a Calculated Field== In the delegate class you simply create a method with the following naming convention: <code> function field__fieldname(Dataface_Record $record); </code> where the return value is the value that the given record should have for the field ''filedname''. E.g. <code> function field__year($record){ $time = trtotime($record->strval('date')); if ( $time ){ return date('Y', $time)); } else { return ''; } } </code> calculated fields, field__fieldname en init 140 init() Delegate Class Method == Synopsis == This method is called once, just after the table is loaded for the first time. It allows you to specify initialization details, such as [[setSecurityFilters|security filters]]. Note that it takes a single parameter: a Dataface_Table object of the table that is being initialized. == Example == <code> function init(&$table){ .... } </code> en Grafted_fields 158 Grafted fields ==Grafted Fields== ===Introduction=== When there are numerous tables, it is difficult for the user to see get an information that will help one to enter the right data in the right field. So instead of navigating in the relative tables and lose some time, it is more convenient to add a grafted field from that relative table in the table. To be able to sort a column by the content displayed when this content is extracted form a relative table, a grafted field is necessary because the real content is just an id, not the most convenient to sort in human-readable way. ===Procedure=== Two ways to add a grafted filed * The first one is to add a __sql__ statement at the beginning of fields.ini, including the grafted field through a join. <code>__sql__ = "select p.*, d.total from programmation p left join dev d on p.id_programmation=d.id_programmation" </code> * The second one is to create the function __sql__ in the delegate class <code>function __sql__(){ return "select p.*, d.total from programmation p left join dev d on p.id_programmation=d.id_programmation"; } </code> ===Sorting order based on relationship=== The solution is to hide the field with the id and to add the grafted field with the name in the fields.ini <code>[name_programmation] order=10 [id_programmation] visibility:list=hidden </code> ===Debugging=== A couple of things to check for: *1. If you have set blanket default permissions for your fields using the __field__permissions() method you could be disallowing access to the field. *2. If you have set default field visibility in the fields.ini file via the [__global__] section.... *3. Check to make sure that your __sql__ directive is at the beginning of the file and that it is __sql__ and not _sql_ *4. Try to enter an obviously invalid SQL query for the __sql__ directive to see if you get an error (to confirm that it is picking up the __sql__ directive at all). grafted fields, grafted, sorting columns, sort, relative records, relative tables en Clean_the_html_for_the_export 178 Clean the HTML to export data ==Clean HTML tags and entities to export your data== #Override the display() of the field to strip the tags... but this would affect all parts of the application where the HTML fields are displayed. #Create a grafted field, then override its display to show the stripped contents of the HTML area field. e.g. in the fields.ini: <code> __sql__ = "select t.*, null as stripped_field from mytable t" [original_field] widget:type=htmlarea visibility:csv=hidden [stripped_field] visibility:csv = visible visibility:list=hidden visibility:browse=hidden visibility:find=hidden </code> Then in the delegate class: <code> function stripped_field__display($record){ return html_entity_decode(strip_tags($record->val('original_field')), ENT_QUOTES, 'UTF-8'); } </code> en Cached_permissions 179 Cached Permissions ==Cached Permissions== ===Introduction=== When you insert a SQL query in your getPermissions function, this will slow down the app dramatically because this function is called by each query. To resolve this problem, it is better to use cached permissions in your /conf/ApplicationDelegate.php or table/table.php. ===Procedure=== Here is an example : <code> class tables_mytable { private $cachedPerms = null; private function _getCachedPerms($param1, $param2, ..., $paramN){ if ( !isset($this->cachedPerms) ) { $this->cachedPerms = array(); // do some stuff $res = mysql_query("select * from foo where bar=1 and param2='".addslashes($param2)."'"); while ( $row = mysql_fetch_assoc($res) ) $this->cachedPerms[$row['fooid']] = $row; } return $this->cachedPerms; } function getPermissions($record){ // do some stuff $perms = $this->getCachedPerms($param1, $param2, ..., $paramN); return $perms; } }</code> Here, getPermissions() will run a db query on its first request, but subsequent requests will just load the cached value. permissions, cache, quick, query en test_page_34 177 Hello World Hello world en viewable_editable_fields 180 How to make a field editable for some users and only viewable for some other users If we want only some users to edit a field and some other users only to view that field, then we need to define a '''fieldX__permissions()''' method for that field which gives desired permissions for specific users. One solution is as below. ==permissions.ini== <code> [Field Viewer] view=1 edit=0 new=0 [Field Editor extends Field Viewer] new=1 edit=1 </code> ==TableX.php (Delegate class of TableX)== <code> function fieldX__permissions(&$record) { $user=&Dataface_AuthenticationTool::getInstance()->getLoggedInUser(); if($user) { if($user->val('usernameField')=="UserX") $role='Field Viewer'; else if($user->val('usernameField')=="UserY") $role='Field Editor'; return Dataface_PermissionsTool::getRolePermissions($role); } return Dataface_PermissionsTool::NO_ACCESS(); } </code> en column:legend 182 en advmultiselect 183 en loginFailed 184 loginFailed() Application Delegate Trigger [[toc]] The loginFailed() method of the Application Delegate class is executed after a failed login attempt. '''Available since 2.0.1''' ==Example== <code> function loginFailed($username, $userIp, $time){ error_log("Failed login for username: $username at IP $userIp at time $time"); } </code> login permissions failed password en