about 36 about ==About Xataface== [[toc]] Xataface is a flexible and shapable skin that sits on top of MySQL, making it accessible to every-day users. It automatically generates the appropriate forms, lists, and menus for a user to interact with the database without having to know any SQL. It is a full-featured Web application framework, and gives developers the flexibility to customize the features and behavior of their application via configuration files (using the simple INI-file syntax), templates, and plug-ins. A generic application with no customizations is completely functional, but the developer is free to customize things at his leisure. ===Who is Xataface for?=== Xataface is for web developers and database administrators who would like to build a front-end for their MySQL database. However the resulting applications are targeted at non-technical users such as secretaries. ===Requirements=== ====Xataface 1.1.x and below:==== * MySQL 3.23+ * PHP 4+ Some advanced features require MySQL version 4.1 or higher. ====Xataface 1.2 and higher==== * MySQL 3.23+ * PHP 5+ Some advanced features require MySQL version 5 or higher. ===At a Glance: Your first App=== # Create a directory for your app. # Copy the ''xataface'' directory inside your application directory. # Create a configuration file named ''conf.ini'' in your application directory with your database settings:<code> [_database] host=localhost name=mydb user=me password=mypass [_tables] ; A list of tables to include in your application's menu ; These tables must already exist in your database people=Profiles news=News Articles </code> # Create an .htaccess file in your application directory to prevent access to your ''conf.ini'' file:<code> <FilesMatch "\.ini$"> Deny from all </FilesMatch> </code> # Create a PHP script in your application directory as an access point for your app. We'll call it ''index.php'':<code style="php"> <?php // Include the Xataface API require_once 'xataface/dataface-public-api.php'; // Initialize Xataface framework df_init(__FILE__, 'xataface'); // first parameter is always the same (path to the current script) // 2nd parameter is relative URL to xataface directory (used for CSS files and javascripts) // Create a new application $app =& Dataface_Application::getInstance(); // Display the application $app->display() </code> # You're done. Your app is ready to use! This is just the beginning, though. There is no limit to the customizations you can make on your application. Read the [http://xataface.com/documentation/tutorial/getting_started Getting Started Tutorial] for more information on developing applications with Xataface. ===Product Comparison=== Xataface fits a niche that is not well covered by existing apps/frameworks. Xataface is '''NOT''': * A database administration system like PHPMyAdmin * Simply a software library/Framework like PHPCake * Simply a content management system like Drupal * A code generator Xataface is a framework, but it is not a typical framework. Most frameworks require a substantial amount of development before you get a usable application. Xataface, on the other hand, provides you with a fully-functional application with as little as 4 lines of PHP code. It doesn't generate any code so it is easy to maintain your application and expand on it later. As a development framework, Xataface most closely resembles Django, a python framework for building data-driven applications. As an application, Xataface most closely resembles Filemaker, a popular relational database that makes it easy for the end user to create layouts and manage their data. ===Features=== ====General==== * '''Out-of-the-box Database Front-end''' - With as little as 4 lines of PHP code, you can have a full-featured web application for your database. * '''Simple, Intuitive User interface''' - Default application is consistent and simple to use. There is a 'tables' menu, to select a table, and each table has "details", "list", and "find" tabs. Very easy to navigate. * '''Powerful configuration options''' - You can configure your application details (such as widget types) using simple configuration files. * '''Extendible''' - You can modify your application as you see fit using configuration files and PHP delegate classes. * '''Hooks''' - By observing simple conventions you can extend Xataface's functionality with hooks, triggers, and events. E.g. add a function that is called after a record is inserted. * '''Permissions''' - Powerful, pluggable permissions system. * '''Authentication''' - Provides login/logout ability. You just specify which table your users are stored in. * '''Relationships''' - Tell Xataface how your tables are related to one another and it will provide you with more logical functionality for managing your data. * '''Themeable''' - Xataface uses the Smarty template engine as a base, but extends it with some powerful new features such as extendable templates and theming support. * '''Modular''' - There are several add-on modules available to extend the features of Xataface even further, and a simple API for writing your own modules. ====Editing==== * '''Automatic Form Generation''' - Automatically generates appropriate web forms to add new records and edit existing records. * '''Widgets''' - Support for many different widget types including text fields, text areas, checkboxes, select lists, html editors, grids, file uploads, and more. * '''Configurable''' - Customize forms using configuration files and delegate classes. * '''Personalizable''' - Show different forms to different users depending on their permissions and preferences. * '''Add Related Records''' - Insert records and automatically track their relationships to other tables. * '''Editable Data Grid''' - Manage your data like a spreadsheet using the DataGrid module. * '''Copy''' - Copy sets of records. * '''Update Found Set''' - Update multiple records with one swipe. * '''Fine-grained Permissions''' - Assign editing permission based on table, record, or field. * '''File uploads''' - Support for file uploads with storage either in a BLOB field or on the file system. * '''Delete''' - Delete single record or delete the current found set. ====Searching==== * '''Automatic Find Form''' - The Xataface find form allows you to search a table on any field. * '''Range Searches''' - Search for records matching values in a certain range (e.g. find all people between the ages of 20 and 30). * '''Exact Matching''' - Search for exact matches. * '''Partial Matching''' - Search for fields that contain a keyword phrase. * '''Multi-field search''' - There is always a simple search field accessible which searches all fields in the current table. E.g. a search for "Tom" would match any record in the current table that contained the phrase "Tom" in any of its columns. * '''Related Record Searches''' - Find records that contain related records matching a search term. (E.g. find all people who got an 'A' in a particular course). ====Browsing==== * '''Automatic Details View''' - Each record has user-friendly details page to browse the contents of the record. * '''AJAX Record Tree''' - Provides optional AJAX record tree to browse the data in your database by relationships. * '''Expand for More''' - Quickly expand a row in list view to see the full record details. * '''Drag and Drop Reordering''' - The details view for a record can be broken up into related sections. Users can reorder these sections via drag and drop. ====Exporting==== * '''RSS''' - Support for RSS 1.0, 2.0 and Atom feeds of any found set. * '''XML''' - Export any found set as XML so that the data can be interchanged with other products (e.g. desktop publishing suites). * '''CSV''' - Export any found set to CSV (comma-separated-value) to open in a spreadsheet application like Excel. * '''JSON''' - Export any found set to JSON. This feature makes Xataface a good choice for serving the next generation of Web 2.0 AJAX applications. ====Internationalization==== * '''String Internationalization''' - Xataface fully supports internationalizing your application. It provides you with language files to provide translations of all of the strings and labels in your application. * '''Dynamic Data Translation''' - Xataface even allows you to internationalize your existing database data without having to change your database structure. * '''Templates''' - Includes a {translate} tag for Smarty templates to easily translate template text. * '''In the background''' - You can use Xataface to internationalize any PHP/MySQL website without having to make any drastic changes to your existing code. Just include Xataface as a library and use some of its useful internationalization functions to convert your application into multiple languages. * '''Translation Form''' - If multiple languages are enabled, Xataface provides a simple translation form to translate content between languages. * '''Translation Status Tracking''' - Track the status of translations to mark whether they need to be retranslated. ====Importing==== * '''Import Filter API''' - Using delegate classes, it is easy to define an import filter to import any type of data into the database. * '''User Preview''' - User can preview imported data before confirming that he wants to import it. ====History==== * '''Optional History Support''' - If history is enabled, all changes made to any data are recorded. * '''Undo/Redo Support''' - Easily revert to an earlier version of a record. * '''View Snapshot''' - Browse previous versions of records. * '''View Diffs''' - View differences/changes between versions of records, similar to a wiki. ====Caching==== * '''Output cache''' - Supports output cache that caches output of pages to improve performance dramatically for busy sites. Cache is automatically refreshed whenever changes are made to tables that are used to generate the page. * '''APC Support''' - If APC (Alternate PHP Cache) is installed, Xataface will automatically use it to cache table configuration information. This tends to increase performance by about 20%. ====Security==== * '''Fine-grained permissions''' - Define permissions to the entire application, a single table, by the record, or by the field. Each feature has an associated permission that can be allowed or disallowed on a per-user basis. * '''Cascading Permissions''' - You can very restrictive permissions to the application as a whole and then apply more permission permissions to specific tables or fields that you want uses to be able to access. Table permissions override application permissions. Field permissions override field permissions. * '''Role-based permissions''' - You can define """roles""" which are sets of permissions that can be assigned to users. * '''Extendable Permissions Model''' - You can easily define your own permissions and roles, extending existing roles, custom for your application. * '''Built-in Authentication''' - It is easy to set up login/logout features for your application. Just tell Xataface which table you store your user records in, and Xataface will do the rest. * '''Password Encryption''' - Xataface supports and is compatible with most of the standard password encryptions including MD5, SHA1, and MySQL Password. * '''Pluggable Authentication''' - Easy to create your own authentication plugins in case you want to implement your own custom authentication. * '''CAS''' - Module available for the Yale CAS (Central Authentication Service). * '''LDAP''' - LDAP authentication module available. * '''HTTP''' - Optional HTTP login support. Standard login uses a web-based login form, but you can also use HTTP headers for authentication. ====Relationships==== * '''Powerful Relationship Model''' - It is easy to define relationships between your tables using simple configuration files. Syntax is simple, but the results are powerful. * '''Add New Related Record''' - Create a new record and add it to a parent record's relationship at the same time. (E.g. create a new "course" record and add it to a teacher's list of taught courses). * '''Add Existing Related Record''' - Add an existing record to a parent record's relationship. (e.g. Add an existing course record to a teacher's list of taught courses). * '''Remove related record''' - Remove a record from a relationship. (e.g. remove a course record from a teacher's list of taught courses). ====API==== Xataface includes a powerful API to allow you to more efficiently work with your database. * '''Data Objects''' - Provides a simple API to work with database records. Searching, loading, saving, editing, and deleting records supported. ====Templates==== * '''Smarty Template Engine''' - Xataface uses the Smarty template engine as a base, one of the fastest PHP template engines available. * '''Template Inheritance''' - You can create templates that inherit from other templates, and replace the content in specified "slots" of the original template. This drastically increases template reuse and development productivity. * '''Cascading Support''' - All system templates are stored in the Dataface/templates directory. Your application can have its own templates directory where you can place templates to override system templates. All parts of the system can be overridden without modifying the original templates themselves. ====Themes==== Xataface includes a powerful themes API. You can create multiple looks for your application and switch between them with a simple configuration setting. ====REST Support==== Xataface's intelligent URL protocols make it a powerful platform for REST web services. You can specify a query directly in the URL to obtain the exact found-set that you want. This is also very useful in standard web applications because you can easily create links to desired parts of your application. Or you can use Xataface to provide missing functionality in your existing applications and link only to the parts of your Xataface app that you need. ===History=== Xataface (formerly Dataface) was originally created by Steve Hannah in 2005 to increase productivity created data-driven applications for Simon Fraser University. He came from faculty that used Filemaker extensively for their databases. As a PHP developer he preferred open technologies like MySQL as they provided fewer "road blocks", but it was hard to deny the benefits of filemaker when it came to providing users with an instant user interface for their databases. It was difficult to justify spending 3 weeks building an administration console for a MySQL application when it could have been done in 3 hours had Filemaker been used. Xataface was designed to: # Increase developer productivity to the point where MySQL applications could be created as quickly as Filemaker applications without sacrificing usability and functionality. # Add an abstraction over a database to make is accessible to non-technical users. The secretary shouldn't need to know SQL in order to interact with a database. # Test the limits of PHP and MySQL As it was built with the intention of providing an alternative for Filemaker, many implementation details and concepts have been inspired by Filemaker. For example, Xataface's implementation of relationships is very similar to Filemaker relationships; as are valuelists. In addition the method of searching follows many Filemaker conventions. The first application built with Xataface was a group content management system for the Faculty of Applied Sciences at Simon Fraser University. This system was used by faculty to manage their research profiles and their research groups. The database itself pre-existed the Xataface implementation. Xataface was used to build a new administrative interface to the system. Since then Xataface has been used to develop many systems for SFU including website content management systems, auctions, event registration systems, research databases, shopping carts, and more. ==Where to go from here== * [http://xataface.com/documentation/tutorial/getting_started Getting Started Tutorial] * [http://xataface.com/videos Watch Demonstration Videos of Xataface] * Sign up for the Xataface Maillist to receive free updates and development tips. (See sign-up form in upper left of the page). en 0 actions.ini_file 6 actions.ini_file ==actions.ini file Reference== [[toc]] The actions.ini file stores information about the various [[action]]s that can be performed by your application. An action may be manifested in two ways: # As a web page # As a menu item And there is no reason why an action cannot serve in both capacities simultaneously. All menu items and functions that Xataface performs are defined in the Xataface actions.ini file (in the root of the Xataface installation dirctory). You can also create an actions.ini file in your application's root directory to override existing Xataface actions, or to create your own. If you want to modify an existing action instead of overriding it, you can use this syntax. <code> [browse > browse] label = Browse </code> The > symbol simply means to inherit from the existing browse action. All the attributes are the same, and we just override the label to Browse (originally was Details) Additionally, for actions that pertain only to a single table, an actions.ini file may be placed in any [[table configuration directory]]. ===Syntax=== As with the [[fields.ini file]] and the [[valuelists.ini file]], the actions.ini file uses the simple [[INI file syntax]] to define its actions. Each action is defined in its own section, and can have a number of directives to specify the action's behavior. Here is a snippet from the Xataface actions.ini file to give you an idea: <code> ;; Show the details of the current record [browse] label = Details category = table_tabs url = "{$this->url('-action=view')}" accessKey = "b" mode = browse permission = view order=0 ;; Show a list of the records in the current found set [list] label = List category = table_tabs url = "{$this->url('-action=list')}" accessKey = "l" mode = list template = Dataface_List_View.html permission = list order=0.5 ;; Show a "Find Record Form" [find] label = Find category = table_tabs url = "{$this->url('-action=find')}" accessKey = "f" mode = find permission = find template = Dataface_Find_View.html order=0.75 </code> This snippet shows the definition of the browse, list, and find actions - three of the most central actions in a Xataface application. Notice how each action has its own section (according to [[INI file syntax]]) with a number of directives which specify how the action behaves. For instance, each action has a "category" value of "table_tabs", which tells Xataface to display the actions as part of the table tabs in the user interface. ===Directives=== {| class="listing listing2" |- ! Name ! Description ! Version |- | [[action allow_override|allow_override]] | An optional directive to indicate that this action can be overridden by more specific directives in another ini file. Currently there is only support for a value of "relationships.ini" indicating that the settings can be overridden in the relationships.ini file. In order for this to work, related=1 must also be set. | 1.3rc4 |- | [[action label|label]] | The label to display if the action is used as a menu item. | all |- | [[action category|category]] | The name of the action's category which can be used to group this action together with other similar actions to be used in a menu in the user interface. | all |- | [[action url|url]] | If the action appears as a menu item, this is the URL that the menu item points to. This may contain PHP expressions inside curly braces. | all |- | [[action accessKey|accessKey]] | The key code to automatically select this action if it is included as a menu item. I.e. ALT+accessKey calls the action. | all |- | [[action mode|mode]] | This indicates which tab of the table tabs (find, details, list, etc...) that this action should appear to be part of when the action is viewed as a web page. If this is left undefined, or it does not match any existing visible action in the table tabs, then no tab will appear to be selected. | all |- | [[action permission|permission]] | The name of a permission required to both see the action as part of a menu and to access the action as a web page. | all |- | [[action visible|visible]] | A boolean value indicating whether the action should be visible as a menu item. | all |- | [[action condition|condition]] | A boolean value or a PHP expression evaluating to a boolean value to indicate whether the action should be visible as a menu item. | all |- | [[action url_condition|url_condition]] | A PHP expression evaluating to a boolean value to indicate whether the URL directive should be evaluated. This basically checks to make sure that its OK to evaluate the "url" expression, just in case the current state of affairs would cause it to throw a fatal error. | all |- | [[action order|order]] | A numeric value indicating the order in which the action should be displayed as part of a menu. Low numbers result in higher placement in the menu. | all |- | [[action icon|icon]] | The path to an icon that should be used when the action appears as a menu item. | all |- | [[action template|template]] | The path to the template that should be used when the action is displayed as a web page. | all |- | [[action description|description]] | Mouseover text for the action (when displayed as a menu item). | all |} ===PHP Expression Context=== Notice that the [[action url|url]], [[action condition|condition]], and [[action url_condition|url_condition]] directives allow you to use a PHP expression for their values. In order for this to be helpful, you should know a little bit about the context and environment in which these expressions will be executed. All expressions are evaluated immediately prior to being rendered, so the same action can be displayed multiple times in the same page, but have very different resulting values for their [[action url|urls]] and [[action condition|conditions]]. These expressions are all executed within the context of the Dataface_Application::parseString() method, with the following variables loaded in the local symbol table (i.e. you can use the following variables in your expressions). {| class="listing listing2" |- ! Name ! Description ! Version |- | [[action context:site_url|$site_url]] | The URL to the current application's directory (not including "index.php") | all |- | $site_href | The URL to the current application including "index.php" | all |- | $dataface_url | The URL to the xataface installation directory. | all |- | $table | The name of the current table (i.e. the value of the "-table" request parameter" | all |- | $query | An associative array of the current query variables. | all |- | $app | A reference to the current Dataface_Application object. Alias of "$this" | all |- | $resultSet | A reference to the Dataface_QueryTool object for the current query. | all |- | [[action context:record|$record]] | A reference to the current Dataface_Record object. | all |- | [[action context:context|$context]] | An associative array of context variables that are passed to the action from the context in which the action is called. | all |} en 0 advmultiselect 183 en afterRegister 14 afterRegister ==afterRegister() Trigger== A trigger that can be implemented in the [[Application Delegate Class]] or the [[Table Delegate Class]], to be executed after the registration form is saved. This can be used to perform some custom actions like emailing the administrator. ===Signature=== function afterRegister( Dataface_Record &$record ) : mixed ====Parameters==== {| class="listing listing2" ! Name ! Description |- | &$record | A Dataface_Record object encapsulating the record that is being inserted in the users table for this registration. |- | returns | Mixed. If this method returns a PEAR_Error object, then registration will fail with an error. |} ===Example=== <code> <?php class conf_ApplicationDelegate { function afterRegister(&$record){ // mail the admin to let him know that the registration is occurring. mail('admin@example.com', 'New registration', 'A new user '.$record->val('username').' has registered); } } </code> ===See Also=== * [[beforeRegister]] * [[validateRegistrationForm]] * [[sendRegistrationActivationEmail]] * [[getRegistrationActivationEmailInfo]] * [[getRegistrationActivationEmailSubject]] * [[getRegistrationActivationEmailMessage]] * [[getRegistrationActivationEmailParameters]] * [[getRegistrationActivationEmailHeaders]] en 0 after_action_new 33 after_action_new ==after_action_new trigger== [[toc]] This trigger is called after the '''new''' action is successfully completed. This trigger can be defined in the table [[Delegate class methods|delegate class]] and is often used to redirect to a particular page after a new record is submitted. This should not be confused with the [[afterInsert]] trigger, which is executed after a record is inserted into the database (this can occur multiple times per request). The after_action_new trigger is only executed once after the 'new' action has been successfully completed. i.e. a maximum of once per request. ===Signature=== <code> function after_action_new($params=array()){ ... } : return void </code> ====Parameters==== This method takes a single associative array as a parameter. This array includes the following keys: * '''record''' - The [http://dataface.weblite.ca/Dataface_Record Dataface_Record] object that was just inserted. ===Examples=== ====Example 1: Redirect to the view tab for the inserted record==== <code> function after_action_new($params=array()){ $record =& $params['record']; header('Location: '.$record->getURL('-action=view').'&--msg='.urlencode('Record successfully inserted.')); exit; } </code> en 0 beforeRegister 13 beforeRegister ==beforeRegister() Trigger== A trigger that can be implemented in the [[Application Delegate Class]] or the [[Table Delegate Class]], to be executed before the registration form is saved. This can be used to perform some custom actions like emailing the administrator. ===Signature=== function beforeRegister( Dataface_Record &$record ) : mixed ====Parameters==== {| class="listing listing2" ! Name ! Description |- | &$record | A Dataface_Record object encapsulating the record that is being inserted in the users table for this registration. |- | returns | Mixed. If this method returns a PEAR_Error object, then registration will fail with an error. |} ===Example=== <code> <?php class conf_ApplicationDelegate { function beforeRegister(&$record){ // mail the admin to let him know that the registration is occurring. mail('admin@example.com', 'New registration', 'A new user '.$record->val('username').' has registered); } } </code> ===See Also=== * [[afterRegister]] * [[validateRegistrationForm]] * [[sendRegistrationActivationEmail]] * [[getRegistrationActivationEmailInfo]] * [[getRegistrationActivationEmailSubject]] * [[getRegistrationActivationEmailMessage]] * [[getRegistrationActivationEmailParameters]] * [[getRegistrationActivationEmailHeaders]] en 0 blob 55 blob en 0 block__blockname 11 block__blockname ===Available Blocks=== This is a grep to show the blocks that are defined in Xataface templates: * Dataface_ActionsMenu.html:actions_menu_head * Dataface_ActionsMenu.html:actions_menu_tail * Dataface_Add_Existing_Related_Record.html:before_add_existing_related_record_form * Dataface_Add_Existing_Related_Record.html:before_add_existing_related_`$ENV.relationship`_form * Dataface_Add_Existing_Related_Record.html:after_add_existing_related_`$ENV.relationship`_form * Dataface_Add_Existing_Related_Record.html:after_add_existing_related_record_form * Dataface_Add_New_Related_Record.html:before_add_new_related_record_form * Dataface_Add_New_Related_Record.html:before_add_new_related_`$ENV.relationship`_form * Dataface_Add_New_Related_Record.html:after_add_new_related_`$ENV.relationship`_form * Dataface_Add_New_Related_Record.html:after_add_new_related_record_form * Dataface_AjaxEventDetails.html:before_event_details * Dataface_AjaxEventDetails.html:after_event_details * Dataface_Delete_Record.html:before_delete_record_form * Dataface_Delete_Record.html:after_delete_record_form * Dataface_Edit_Record.html:before_edit_record_form * Dataface_Edit_Record.html:after_edit_record_form * Dataface_FindForm.html:findform_before_`$element.field.name`_row * Dataface_FindForm.html:findform_before_`$element.field.name`_widget * Dataface_FindForm.html:findform_after_`$element.field.name`_widget * Dataface_FindForm.html:findform_after_`$element.field.name`_row * Dataface_FindForm.html:before_findform_table * Dataface_FindForm.html:findform_before_`$element.field.name`_row * Dataface_FindForm.html:findform_before_`$element.field.name`_widget * Dataface_FindForm.html:findform_after_`$element.field.name`_widget * Dataface_FindForm.html:findform_after_`$element.field.name`_row * Dataface_FindForm.html:after_findform_table * Dataface_Find_View.html:before_find_form * Dataface_Find_View.html:after_find_form * Dataface_Form_Section_Template.html:before_quickform_table * Dataface_Import_RelatedRecords.html:before_import_related_records_form * Dataface_Import_RelatedRecords.html:before_import_related_`$ENV.relationship`_form * Dataface_Import_RelatedRecords.html:after_import_related_`$ENV.relationship`_form * Dataface_Import_RelatedRecords.html:after_import_related_records_form * Dataface_List_View.html:before_result_list * Dataface_List_View.html:after_result_list * Dataface_Login_Prompt.html:before_login_form * Dataface_Login_Prompt.html:after_login_form * Dataface_Main_Template.html:custom_stylesheets2 * Dataface_Main_Template.html:head * Dataface_Main_Template.html:body_atts * Dataface_Main_Template.html:before_body * Dataface_Main_Template.html:before_header * Dataface_Main_Template.html:after_header * Dataface_Main_Template.html:before_search * Dataface_Main_Template.html:after_search_form_submit * Dataface_Main_Template.html:after_search * Dataface_Main_Template.html:before_nav_menu * Dataface_Main_Template.html:after_nav_menu * Dataface_Main_Template.html:before_language_selector * Dataface_Main_Template.html:after_language_selector * Dataface_Main_Template.html:before_user_status_logged_in * Dataface_Main_Template.html:after_user_status_logged_in * Dataface_Main_Template.html:before_user_status_not_logged_in * Dataface_Main_Template.html:after_user_status_not_logged_in * Dataface_Main_Template.html:before_personal_tools * Dataface_Main_Template.html:after_personal_tools * Dataface_Main_Template.html:before_bread_crumbs * Dataface_Main_Template.html:after_bread_crumbs * Dataface_Main_Template.html:before_main_table * Dataface_Main_Template.html:before_left_column * Dataface_Main_Template.html:before_record_tree * Dataface_Main_Template.html:after_record_tree * Dataface_Main_Template.html:before_nav_menu * Dataface_Main_Template.html:after_nav_menu * Dataface_Main_Template.html:before_application_menu * Dataface_Main_Template.html:after_application_menu * Dataface_Main_Template.html:after_left_column * Dataface_Main_Template.html:before_main_column * Dataface_Main_Template.html:before_message * Dataface_Main_Template.html:message * Dataface_Main_Template.html:after_message * Dataface_Main_Template.html:before_errors * Dataface_Main_Template.html:error * Dataface_Main_Template.html:after_errors * Dataface_Main_Template.html:before_table_tabs * Dataface_Main_Template.html:before_menus * Dataface_Main_Template.html:after_menus * Dataface_Main_Template.html:before_main_section * Dataface_Main_Template.html:before_recently_viewed * Dataface_Main_Template.html:after_recently_viewed * Dataface_Main_Template.html:before_record_content * Dataface_Main_Template.html:after_record_content * Dataface_Main_Template.html:after_main_section * Dataface_Main_Template.html:before_fineprint * Dataface_Main_Template.html:after_fineprint * Dataface_Main_Template.html:before_global_footer * Dataface_Main_Template.html:after_global_footer * Dataface_Main_Template.html:before_main_section * Dataface_Main_Template.html:before_recently_viewed * Dataface_Main_Template.html:after_recently_viewed * Dataface_Main_Template.html:before_record_content * Dataface_Main_Template.html:after_record_content * Dataface_Main_Template.html:after_main_section * Dataface_NavMenu.html:tables_menu_head * Dataface_NavMenu.html:tables_menu_tail * Dataface_NavMenu.html:tables_menu_head * Dataface_NavMenu.html:tables_menu_tail * Dataface_New_Record.html:before_new_record_form * Dataface_New_Record.html:after_new_record_form * Dataface_Record_Template.html:before_details_controller * Dataface_Record_Template.html:after_details_controller * Dataface_Record_Template.html:before_record_heading * Dataface_Record_Template.html:after_record_heading * Dataface_Record_Template.html:before_record_tabs * Dataface_Record_Template.html:before_record_content * Dataface_Record_Template.html:after_record_content * Dataface_Record_Template.html:before_record_footer * Dataface_Record_Template.html:after_record_footer * Dataface_Registration.html:before_registration_form * Dataface_Registration.html:after_registration_form * Dataface_Related_Records_List.html:before_related_`$ENV.relationship`_records_list * Dataface_Related_Records_List.html:after_related_`$ENV.relationship`_records_list * Dataface_Remove_Related_Record.html:before_remove_related_record_form * Dataface_Remove_Related_Record.html:before_remove_related_`$ENV.relationship`_record_form * Dataface_Remove_Related_Record.html:after_remove_related_`$ENV.relationship`_record_form * Dataface_Remove_Related_Record.html:after_remove_related_record_form * Dataface_View_Record.html:before_view_tab_content * Dataface_View_Record.html:before_record_actions * Dataface_View_Record.html:after_record_actions * Dataface_View_Record.html:after_view_tab_content * Dataface_related_records_checkboxes.html:before_related_`$ENV.relationship`_records_checkboxes * Dataface_related_records_checkboxes.html:before_related_records_checkboxes * Dataface_related_records_checkboxes.html:after_related_records_checkboxes * Dataface_related_records_checkboxes.html:after_related_`$ENV.relationship`_records_checkboxes * Dataface_set_translation_status.html:before_details_controller * Dataface_set_translation_status.html:after_details_controller ===Available Slots=== * Dataface_ActionsMenu.html:actions_menu * Dataface_Add_Existing_Related_Record.html:add_existing_related_`$ENV.relationship`_form * Dataface_Add_Existing_Related_Record.html:add_existing_related_record_form * Dataface_Add_New_Related_Record.html:add_new_related_`$ENV.relationship`_form * Dataface_Add_New_Related_Record.html:add_new_related_record_form * Dataface_AjaxEventDetails.html:event_details * Dataface_Delete_Record.html:delete_record_form * Dataface_Edit_Record.html:edit_record_form * Dataface_FindForm.html:findform_`$element.field.name`_row * Dataface_FindForm.html:findform_`$element.field.name`_widget * Dataface_FindForm.html:findform_`$element.field.name`_row * Dataface_FindForm.html:findform_`$element.field.name`_widget * Dataface_Find_View.html:find_form * Dataface_Import_RelatedRecords.html:import_related_`$ENV.relationship`_form * Dataface_Import_RelatedRecords.html:import_related_records_form * Dataface_List_View.html:result_list * Dataface_List_View_summary.html:result_list * Dataface_Login_Prompt.html:login_form * Dataface_Main_Template.html:doctype_tag * Dataface_Main_Template.html:html_tag * Dataface_Main_Template.html:html_head * Dataface_Main_Template.html:html_title * Dataface_Main_Template.html:dataface_stylesheets * Dataface_Main_Template.html:custom_stylesheets * Dataface_Main_Template.html:dataface_javascripts * Dataface_Main_Template.html:custom_javascripts * Dataface_Main_Template.html:head_slot * Dataface_Main_Template.html:html_body * Dataface_Main_Template.html:global_header * Dataface_Main_Template.html:search_form * Dataface_Main_Template.html:language_selector * Dataface_Main_Template.html:user_status_logged_in * Dataface_Main_Template.html:user_status_not_logged_in * Dataface_Main_Template.html:personal_tools * Dataface_Main_Template.html:bread_crumbs * Dataface_Main_Template.html:main_table * Dataface_Main_Template.html:left_column * Dataface_Main_Template.html:application_menu * Dataface_Main_Template.html:main_column * Dataface_Main_Template.html:table_tabs * Dataface_Main_Template.html:menus * Dataface_Main_Template.html:main_section * Dataface_Main_Template.html:record_content * Dataface_Main_Template.html:fineprint * Dataface_Main_Template.html:global_footer * Dataface_Main_Template.html:main_section * Dataface_Main_Template.html:record_content * Dataface_Main_Templateold.html:doctype_tag * Dataface_Main_Templateold.html:html_tag * Dataface_Main_Templateold.html:html_head * Dataface_Main_Templateold.html:html_title * Dataface_Main_Templateold.html:dataface_stylesheets * Dataface_Main_Templateold.html:custom_stylesheets * Dataface_Main_Templateold.html:dataface_javascripts * Dataface_Main_Templateold.html:custom_javascripts * Dataface_Main_Templateold.html:head_slot * Dataface_Main_Templateold.html:html_body * Dataface_Main_Templateold.html:global_header * Dataface_Main_Templateold.html:search_form * Dataface_Main_Templateold.html:language_selector * Dataface_Main_Templateold.html:user_status_logged_in * Dataface_Main_Templateold.html:user_status_not_logged_in * Dataface_Main_Templateold.html:personal_tools * Dataface_Main_Templateold.html:bread_crumbs * Dataface_Main_Templateold.html:main_table * Dataface_Main_Templateold.html:left_column * Dataface_Main_Templateold.html:application_menu * Dataface_Main_Templateold.html:main_column * Dataface_Main_Templateold.html:table_tabs * Dataface_Main_Templateold.html:menus * Dataface_Main_Templateold.html:main_section * Dataface_Main_Templateold.html:record_content * Dataface_Main_Templateold.html:fineprint * Dataface_Main_Templateold.html:global_footer * Dataface_Main_Templateold.html:main_section * Dataface_Main_Templateold.html:record_content * Dataface_NavMenu.html:tables_menu_options * Dataface_NavMenu.html:tables_menu_options * Dataface_New_Record.html:new_record_form * Dataface_Record_Template.html:record_heading * Dataface_Record_Template.html:record_content * Dataface_Record_Template.html:record_footer * Dataface_Registration.html:registration_form * Dataface_Related_Records_List.html:before_related_list * Dataface_Related_Records_List.html:related_`$ENV.relationship`_records_list * Dataface_Related_Records_List.html:related_records_list * Dataface_Related_Records_List.html:after_related_list * Dataface_Remove_Related_Record.html:remove_related_`$ENV.relationship`_record_form * Dataface_Remove_Related_Record.html:remove_related_record_form * Dataface_View_Record.html:view_tab_content * Dataface_View_Record.html:record_actions * Dataface_View_Record.html:record_search * Dataface_View_Record.html:`$section.name`_section_content * Dataface_View_Record.html:record_view_main_section * Dataface_View_Record.html:`$section.name`_section_content * Dataface_related_records_checkboxes.html:related_`$ENV.relationship`_records_checkbox_form * Dataface_related_records_checkboxes.html:related_records_checkbox_form * global_header.html:site_logo en 0 Calendar_Action 43 Calendar_Action ==Calendar Action== [[toc]] Xataface 1.0 includes a built-in calendar action that is disabled by default. If enabled, it allows you to view the records in any found set as a calendar of events, as follows: <nowiki> <div style="text-align:center;border: 1px solid #ccc; padding: 10px"> <img src="http://media.weblite.ca/files/photos/Picture -4.png?max_width=500" onmouseover="this.src='http://media.weblite.ca/files/photos/Picture -4.png';" onmouseout="this.src='http://media.weblite.ca/files/photos/Picture -4.png?max_width=500';"/> </div> </nowiki> ===Features=== * Monthly display * Hourly schedule for any day by clicking on it. * Show record details instantly by clicking on it in the calendar. * Recognizes dates, start and end times for records when interpreted as calendar events. * Respects searches (i.e. you can filter the records and the calendar will only show those records in the found set). ===Requirements=== Your table records should contain at least dates in order for them to be interpreted as events that can be placed in a calendar. ===Setting up the Calendar=== Suppose I have a table called ''Lessons'' that stores information about scheduled music lessons. If I want to add the calendar to this table, then I would add an ''[[actions.ini file]]'' to the ''tables/Lessons'' directory with the following contents:<code> [calendar > calendar] condition="true" </code> This overrides the calendar action which is disabled by default, and enables it for the ''Lessons'' table. Next I need to inform Xataface which fields store the event dates and times so that the records can be laid out in the calendar appropriately. (Note that if you skip this step, Xataface will make a best guess based on column types and names - but it is better to specify these explicitly). In the ''Lessons'' table I have the following fields that are relevant here: * ''lesson_date'' - A date field containing the date and start time of the event. * ''start_time'' - A time field with the start time of the lesson. We can tell Xataface to treat these fields accordingly by adding the following directives to the appropriate field sections of the [[fields.ini file]] for the ''Lessons'' table: * ''event.date=1'' - Specifies that the field stores the date of the event. * ''event.start=1'' - Specifies that the field stores the start time of the event. So in our case we'll modify the [[fields.ini file]] as follows: <code> [lesson_date] event.date=1 [start_time] event.start=1 </code> Now if we load up our application, we should now see a ''calendar'' tab along side ''list'', ''details'', and ''find'' for the ''Lessons'' table. Click on this tab to see your records displayed in a calendar. ===Using a datetime field to store both date and start time=== You can also use a single field to store both the date and start time for an event. In this case you just provide the ''event.date'' and ''event.start'' directives for the same field. For example if the ''lesson_date'' was a datetime field that marked the date and time of the lesson, we would modify our [[fields.ini]] file as follows: <code> [lesson_date] event.date=1 event.start=1 </code> ===Available Fields=== The Calendar action will look for the following pieces of information in your records: {| class="listing listing2" ! Name ! Description ! Version |- | event.date | Indicates that the field contains the date of the event. | 1.0 |- | event.start | Indicates that the field contains the start time of the event. | 1.0 |- | event.end | Indicates that the field contains the end time of the event. | 1.0 |- | event.location | Indicates that the field contains the location of the event. | 1.0 |- | event.category | Indicates that the field contains the category of the event. | 1.0 |} en 0 checkbox 69 checkbox ==The checkbox widget== In the [[fields.ini file]] you can specify a field to be edited using a checkbox widget by setting [[widget:type]] to [[checkbox]]. A checkbox widget can function in 2 different ways depending on the parameters that you assign to the field. [[toc]] ===Example 1: A TinyInt (boolean) field=== Suppose our table has a tinyint field named "Active" which specifies whether the record is currently in use. This field will store a value of either 0 or 1. So we configure this field in our [[fields.ini]] file to use a checkbox widget as follows: <code> [Active] widget:type=checkbox </code> Results: [[Image:http://media.weblite.ca/files/photos/Picture%2024.png?max_width=640]] ===Example 2: A repeating field (multiple checkboxes for one field=== Checkboxes can store multiple values in a single field by setting the [[vocabulary]] directive and applying it to a varchar or text field. In this case there will be one value saved per line. In this example, suppose we have a varchar field named '''categories''' which uses the '''categories''' [[valuelist]] to specify the different categories that can be checked at any given time. Our [[valuelists.ini file]] might look like: <code> [categories] __sql__ = "select id,name from categories" </code> And our [[fields.ini file]] looks like: <code> [categories] widget:type=checkbox vocabulary=categories </code> * Note that you don't need to name the field the same as the valuelist. It just worked out this way. Now if we save a record with categories 1, 3, and 5 checked, then the categories column of our row in the database will store something like: <code> 1 3 5 </code> i.e. one category id per line. Note that using this method, your database will not be normalized because you are storing multiple values in a single field. However in many applications this is sufficient. Results: [[Image:http://media.weblite.ca/files/photos/Picture%2025.png?max_width=640]] ===Example 3: Using a "Categories" relationship=== """(Note: This example requires Xataface version 1.2 or higher)""" Example 2 above shows how we can easily add and remove a record from multiple categories using checkboxes. However it required multiple pieces of information to be stored in a single database field which may or may not be advantageous for your database design. If you're looking for a more normalized database schema you would probably design your database as follows for this case: # Books table - Stores all of the books. # Categories table - Stores all of the categories # Book_Categories table - Stores mapping of books to categories. With out table structure we will first want to define a relationship from Books to Categories to reflect the connection between books and categories. The [[relationships.ini file]] for this might look like: <code> [categories] Books.Book_ID="$Book_ID" Book_Categories.Category_ID=Categories.Category_ID </code> And our [[fields.ini file]] for the Books table might look like: <code> [categories] widget:type=checkbox transient=1 relationship=categories </code> * Note that there is no need for our field to be named the same as our relationship. It just turned out this way. Also note that we used the transient=1 flag here because the Books table no longer has a categories field in the database. This field is defined purely for the benefit of the edit form so that we will get a checkbox group to select the book's categories. Results: [[Image:http://media.weblite.ca/files/photos/Picture%2025.png?max_width=640]] ==Related Parameters== # [[vocabulary]] - Assigns a valuelist to be used as the options for this checkbox group. # [[repeat]] - A boolean value indicating whether this field should be treated as a 'repeating field'. A repeating field is one with multiple checkboxes. By default the checkbox widget operates as a single checkbox that controls a boolean value. # [[relationship]] - (Only applicable to [[transient]] fields). If the [[relationship]] directive is set then this field can be used to add/remove records from a relationship. en 0 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 column:legend 182 en conf.ini_file 25 conf.ini_file ==conf.ini File== [[toc]] The conf.ini file is where most of the application-level configuration information is stored for a Xataface application. It contains information such as: * database connection information * which tables should appear in the tables menu. * [[preferences|preference settings]] * [[authentication]] settings * which add-on [[modules]] are to be used * output caching settings * history/undo settings * other misc settings. Every conf.ini file must contain at least the following sections: {| class="listing listing2" |- ! Name ! Description ! Version |- | _database | Contains database connection info. | all |- | _tables | Contains a list of tables that are to be included in the navigation menu of the application. | all |} The following optional sections may also be included: {| class="listing listing2" |- ! Name ! Description ! Version |- | [http://xataface.com/documentation/how-to/disallow_tables _allowed_tables] | Specifies tables that should be explicitly allowed to override disallowed tables listed or matched in the [http://xataface.com/documentation/how-to/disallow_tables _disallowed_tables] section. | 0.7 |- | [[_auth]] | Contains information about [[authentication]]. | 0.6 |- | [http://xataface.com/documentation/how-to/disallow_tables _disallowed_tables] | A list of tables or patterns that match tables that should be blocked from being accessed directly through the application. By default any table beginning with an underscore, 'dataface_', or ending in '__history' are blocked. This prevents unintended access to some of the automatically created tables in Xataface. | 0.7 |- | _feed | Configuration options for [[Introduction_to_RSS_Feeds_in_Xataface|RSS feeds]] that are generated by the application. | 1.0 |- | _history | Settings pertaining to the [http://xataface.com/documentation/how-to/history-howto history feature] (e.g. whether it has been enabled). | 0.7 |- | _index | Settings for the full site search indexing. | 1.0 |- | _modules | A list of [[modules]] that are enabled for this application. | 1.0 |- | [[_output_cache]] | Output cache settings. Using output caching can dramatically improve performance for busier sites. | 0.8 |- | _themes | A list of the themes that are to be applied to the application. | 0.8 |} ===Stand-alone Attributes=== Stand-alone attributes for an INI file must appear at the beginning of the INI file (before any of the sections). The conf.ini may contain the following stand-alone attributes. {| class="listing listing2" |- ! Name ! Description ! Values ! Version |- | cache_queries | Enables query caching. Enabling this feature can yield drastic performance improvements especially on busy sites with large databases. | boolean (0 or 1) | 1.2 |- | cache_queries_log | Enables logging of query caching to the file /tmp/querylog.log so that you can tell whether your queries are being cached, and which ones are being cached. | boolean (0 or 1) | 1.2 |- | default_action | The default action to be performed if it is not explicitly specified in the query (e.g. 'list', 'find', 'edit'). Default is 'list'. | string | 0.6 |- | debug | If this is set to 1, then the application will run in debug mode which displays the available slots and blocks on the screen, along with some other debug information. | 0 or 1 (default is 0) | 0.6 |- | default_browse_action | The default action to perform in the details tab. E.g. When you click on the "details" tab there are a number of sub-tabs including 'view', 'edit', etc... . The default value for this directive is 'view'. If you want to go directly to the edit form when clicking on a record in list view, you would set ''default_browse_action'' to 'edit'. | string | 0.6 |- | default_language | The default language to use. This is the 2-digit ISO language code. If this value is not specified it defaults to the first language listed in the ''[languages]'' section. | string (2-digit ISO language code) | 0.6 |- | default_limit | The default limit (i.e. the number of records to show per page) if none is explicitly specified in the query. Default is 30. | int | 0.6 |- | default_table | The default table to show if none is specified by the query. If you do not define this value, then the first table in the ''[_tables]'' section is used. | string |0.6 |- | disable_session_ip_check | Default behaviour automatically tracks the IP address of the user when they log in. If a request is made for a session from a different IP then the session is automatically destroyed and the user is logged out. | boolean | 1.3rc4 |- | title | A title for the application (appears in the browser title bar). | string | 0.6 |- | usage_mode | The usage mode of the application. If this value is set to ''edit'', then ajax inline editing is enabled (i.e. you can click on any value in the application to edit it inline. | 'view' or 'edit' | 0.6 |} ===Example 1: A simple conf.ini file=== <code> [_database] host="localhost" name="mydb" user="mydbuser" password="foo" [_tables] webpage_sites="Websites" translations = "Translations" packages="Packages" users=Users proof_jobs="Jobs" webpage_status="Webpages Status" </code> ===Example 2: A more complex conf.ini file=== <code> ;debug=1 ;default_action=home ;google_translate_url="http://weblite-dns2.com/proxy.php" google_translate_url="http://ec2-75-101-244-123.compute-1.amazonaws.com/proxy.php" title="Web Lite Translate" default_price_per_word=0.15 ;;Configuration settings for application title="translation_weblite_ca" scriptUrl="http://translation.weblite.ca/index.php" multilingual_content=1 [_database] host="localhost" name="mydb" user="mydbuser" password="foo" [_tables] webpage_sites="Websites" translations = "Translations" packages="Packages" users=Users proof_jobs="Jobs" webpage_status="Webpages Status" [_auth] users_table=users username_column=username password_column=password secret_code="ljkasdfjkldsafliasdoiudsfoi" allow_register=1 session_timeout=999999999 [_modules] modules_ShoppingCart="modules/ShoppingCart/ShoppingCart.php" [ShoppingCart_taxes] ;; This section is necessary to declare that we have NO taxes. [metatags] keywords = "translation, translate" description = "Good translation service" ;[_output_cache] ; enabled=1 [_mail] func=mail2 </code> en 0 Creating_Printable_Reports 82 Creating a Custom Printable Report ==Creating a Printable Report== [[toc]] It is often useful to provide your users with a printable report that is generated from your database. Although Xataface doesn't include an explicit reporting module to allow the end users to create their own reports, you (the developer) can still quite easily produce a report by creating a custom action. This report will be subject to the user's sorting and searching preferences. E.g. if the user searches for only books about "frogs", then when he clicks on your printable report it will only display those records that match the query (i.e. only books about frogs). ===Requirements for our report=== # Report will be run against the "products" table (using the WebAuction application). # Report should be accessible by clicking an icon in the top right of the list view (i.e. the resultlist actions). # Report should display the product ID, product name, photo, and description. One product per page. ===Adding the Icon to our Application=== We'll start out by finding an appropriate icon to use for our action. There are loads of free icons that you can download (please observe and respect the license agreement of any icon library that you use). Two good free icon libraries include: # [http://www.famfamfam.com/lab/icons/silk/ FamFamFam Silk Icons] # [http://tango.freedesktop.org/Tango_Icon_Library Tango Icon Library] Once you have found the icon you want to use, just upload it somewhere inside your application's directory. It might be a good idea to create a directory to store your images if you haven't already. An appropriate name might by ''images''. For this example, we'll use the [[Image:http://dev.weblite.ca/phpimageserver/photos/icons/printer.png]] icon from the FamFamFam icon library. So we upload this icon to %APPLICATION_PATH%/images/printer.png Next we need to create an entry in our application's [[actions.ini file]] so that Xataface knows about our action, and where we want its icon to be displayed. We'll start out with a basic definition that just specifies the icon for the action, and the ''category'' of the action. <code> [printable_report] icon="{$site_url}/images/printer.png" category=result_list_actions description="See this product list in a printable format" </code> The ''result_list_actions'' category setting means that the icon for our action will be included along with the result list actions, which are located in the top right corner in the list tab. Now if we reload our application and look at the "list" tab, you'll see that the icon group in the top right now includes our icon: [[Image:http://media.weblite.ca/files/photos/Picture%20-5.png?max_width=640]] If you don't see this icon, but see the text "printable_report" instead, then you have entered an incorrect path to the icon in the ''icon'' directive. If you don't see an icon at all or any text, then your ''category'' directive may be incorrect. Check that it is exactly "result_list_actions". If you mouse over your icon you'll see the text that you specified as your ''description'' directive for the action: [[Image:http://media.weblite.ca/files/photos/Picture%20-6.png?max_width=640]] You'll notice, if you try to click on your icon, that nothing happens. This is because we haven't yet specified a URL for your action. We'll wait to specify our URL, until we've built the back-end of our action (i.e. the actual report). ===Creating the Actual Report=== Most reports involve the following pieces: # Fetch the found set of records from the database. # Loop through the found set and output some information about each record. # Optionally use a template to integrate the report into your application's look and feel. All reports will be placed in the framework of a custom Xataface action. In our case we add a file to our application ''actions'' directory named after our action: %APPLICATION_PATH%/actions/printable_report.php with the following contents: <code> <?php class actions_printable_report { function handle(&$params){ echo "Hello world!!!"; } } </code> Please note the following about this snippet: # The action was placed in a file ''actions/printable_report.php'' because the action is named ''printable_report'' (referring to our definition in the ''[[actions.ini file]]''. If the action was named ''foo'', then we would place our action in file ''actions/foo.php''. # The ''printable_report.php'' file contains a single class named ''actions_printable_report'' after the name of the action. # The action class contains a single method ''handle'' which handles the request for the action (i.e. outputs the report the way we like). This method must exist and me named exactly ''handle''. # The ''handle'' method takes a single ''&$params'' parameter which contains some parameters that may be passed to the action. We won't be dealing with these in this example. Before proceeding, let's try accessing our action just to make sure that we're on the right track. Point your browser to http://example.com/yourapplication/index.php?-action=printable_report Note that you don't point our web browser directly to your action php file (in the ''actions'' directory. Rather you point it to your application's entry point (index.php file), and specify the action via the ''-action'' GET parameter. Your web browser should display something like: [[Image:http://media.weblite.ca/files/photos/Picture%204.png?max_width=640]] If you get a blank white screen, then you should check your error log to see where the error is occuring. See [[Troubleshooting]] for general Xataface troubleshooting strategies in this case. Now that we have all of the formalities out of the way, we can proceed to meat of our report. ====Retrieving the Found Set==== Let's build onto our action now. First we will load the found set of records as follows: <code> <?php class actions_printable_report { function handle(&$params){ $app =& Dataface_Application::getInstance(); $query =& $app->getQuery(); if ( $query['-table'] != 'products' ){ return PEAR::raiseError('This action can only be called on the Products table.'); } $products = df_get_records_array('products', $query); } } </code> Things to note in this snippet: # We start be loading a reference to the ''Dataface_Application'' object. # We then use the ''Dataface_Application'' object to load the current query. This is essentially an associative array of all of the GET parameters, but with some guaranteed attributes such as ''-table'' and ''-action''. # In our particular action we are designing it to only work for the ''products'' table so we do a check on the query parameters to make sure that this is the case. If someone tries to run this action from outside the products table (e.g. if -action=foo) then an error will be displayed. # We use the df_get_records_array() function to return all matching records on the products table. It returns an array of [[Dataface_Record]] objects. ====Overriding -skip and -limit==== Xataface allows the user to specify the number of records to display and the position in the found set to start from by adding the ''-skip'' and ''-limit'' GET parameters to a request. If these are omitted, then default values of 0 and 30 are used respectively. You may notice that if you click "Next" in list view, you see '-skip' and '-limit' parameters automatically added to the URL. ''df_get_records_array'' respects the -limit and -skip parameters that are specified in the query. I.e. if -skip and -limit are omitted it will return only the first 30 records from the found set. If -skip=1 and -limit=10 then it will return 10 records starting from the 2nd record (2nd becuase -skip=0 would point to the first record). This may be desired behavior for your report, but in some reports you may want to print off the entire found set. If this is the case, you will want to explicitly set the -skip and -limit parameters in the ''$query'' array before passing it to ''df_get_records_array''. E.g.: <code> $query =& $app->getQuery(); $query['-skip'] = 0; $query['-limit'] = 10000; $products = df_get_records_array('products', $query); </code> ====Looping through and Printing Product Info==== Now comes the fun part. We're just going to loop through our found set and print off the product information: <code> foreach ($products as $p){ echo '<table>' .'<tr><th>Product ID</th><td>'.$p->htmlValue('product_id').'</td></tr>' .'<tr><th>Product Name</th><td>'.$p->htmlValue('product_name').'</td></tr>' .'<tr><th>Description</th><td>'.$p->htmlValue('product_description').'</td></tr>' .'<tr><th>Photo</th><td>'.$p->htmlValue('product_image').'</td></tr>' .'</table>'; } </code> The entire action at this point will look like: <code> <?php class actions_printable_report { function handle(&$params){ $app =& Dataface_Application::getInstance(); $query =& $app->getQuery(); $query['-skip'] = 0; $query['-limit'] = 10000; if ( $query['-table'] != 'products' ){ return PEAR::raiseError('This action can only be called on the Products table.'); } $products = df_get_records_array('products', $query); foreach ($products as $p){ echo '<table>' .'<tr><th>Product ID</th><td>'.$p->htmlValue('product_id').'</td></tr>' .'<tr><th>Product Name</th><td>'.$p->htmlValue('product_name').'</td></tr>' .'<tr><th>Description</th><td>'.$p->htmlValue('product_description').'</td></tr>' .'<tr><th>Photo</th><td>'.$p->htmlValue('product_image').'</td></tr>' .'</table>'; } } } </code> Now we refresh our action in the web browser, or point the browser again to: http://example.com/yourapplication/index.php?-action=printable_report&-table=products It should display something like: [[Image:http://media.weblite.ca/files/photos/Picture%205.png?max_width=640]] If you get a blank white screen, please check out the [[Troubleshooting]] section for general Xataface troubleshooting strategies. ====Adding a Little Style==== It is a good idea to at least provide the proper HTML HEAD and BODY tags for your report. And to help make things a little nicer looking we're going to add some CSS styles to: # Make the table field labels vertically aligned to the top. # Change the font to helvetica. This is easy to do with simple echo statements: <code> echo '<html><head>' .'<title>Printable Report</title>' .'<style type="text/css">' .' th { vertical-align: top}' .'</style>' .'</head>' .'<body>'; //... </code> So our finished action looks like: <code> <?php class actions_printable_report { function handle(&$params){ $app =& Dataface_Application::getInstance(); $query =& $app->getQuery(); $query['-skip'] = 0; $query['-limit'] = 10000; if ( $query['-table'] != 'products' ){ return PEAR::raiseError('This action can only be called on the Products table.'); } $products = df_get_records_array('products', $query); echo '<html><head>' .'<title>Printable Report</title>' .'<style type="text/css">' .' th { vertical-align: top}' .'</style>' .'</head>' .'<body>'; foreach ($products as $p){ echo '<table>' .'<tr><th>Product ID</th><td>'.$p->htmlValue('product_id').'</td></tr>' .'<tr><th>Product Name</th><td>'.$p->htmlValue('product_name').'</td></tr>' .'<tr><th>Description</th><td>'.$p->htmlValue('product_description').'</td></tr>' .'<tr><th>Photo</th><td>'.$p->htmlValue('product_image').'</td></tr>' .'</table>'; } echo '</body></html>'; } } </code> ===Connecting the Icon to the Action=== FInally it is time to connect our Icon to our Action. We do this by adding a ''url'' directive for the action in the ''[[actions.ini file]]'': <code> [printable_report] icon="{$site_url}/images/printer.png" category=result_list_actions description="See this product list in a printable format" url="{$app->url('-action=printable_report')}" </code> Explanation of the ''url'' directive in this snippet: * The ''url'' method of the ''[[Dataface_Application]]'' object is used to generate a URL with the user's current query settings, but with the ''-action'' parameter set to ''printable_report''. Now if we reload our application, go to the list tab of the ''products'' table and click on our icon, it should take us to our action: [[Image:http://media.weblite.ca/files/photos/Picture%207.png?max_width=640]] ===Trying out the action on different found sets with different sort orders=== One of the cool things about this action is that it is tied directly into the Xataface find settings so that th user is able to search for a subset of products and run our report on only those products that were found. The user can also perform a sort on any column and this sort will be respected by our report. ===Hiding Icon from Other Tables=== Since our action is only intended to operate on the ''products'' table it probably isn't a good idea to make the icon visible for every other table. For example, if you go to the list view of the ''users'' table, you'll see the printer icon in the top right just like it appears for the ''products'' table. Clicking on it should display our error: [[Image:http://media.weblite.ca/files/photos/Picture%206.png?max_width=640]] We will use a ''condition'' directive for our action to hide it from tables other than the ''products'' table as follows: condition="$query['-table'] == 'products'" So our action will now look like: <code> [printable_report] icon="{$site_url}/images/printer.png" category=result_list_actions description="See this product list in a printable format" url="{$app->url('-action=printable_report')}" condition="$query['-table'] == 'products'" </code> Now if you reload the list for the ''users'' table you'll notice that the printer icon is now gone. But returning to the ''products'' table shows our action still alive and well. ===Locking Down our Action with Permissions=== In our case we don't want our action to be accessible to all users. Only administrators. Xataface permissions and all its possibilities are beyond the scope of this tutorial, but we still want to demonstrate how to lock down this action. The WebAuction application into which this action is being installed defines a permission called ''reports'' which only administrators have. We will use this permission to limit access to this action as follows in the actions.ini file: permission=reports So the actions.ini file will now look like: <code> [printable_report] icon="{$site_url}/images/printer.png" category=result_list_actions description="See this product list in a printable format" url="{$app->url('-action=printable_report')}" condition="$query['-table'] == 'products'" permission=reports </code> Now only administrators will see our icon, and if non-administrators attempt to access out action by typing in its URL directly, they will receive an "Access Denied" message. en Customizing_the_look_and_feel_of_a_row_or_a_cell 62 Customizing_the_look_and_feel_of_a_row_or_a_cell ==How to customize the look and feel of elements in the list view== ===Create a method in a delegate class=== In the delegate class, the method ''css__tableRowClass'' is implemented, like in this example : <code>class tables_journal_interventions { function css__tableRowClass(&$record){ if ( !$record->val('fermeture')){ return 'intervention_close'; } else return ''; } } </code> Here the function tests a condition : is there a value in the field ''fermeture'' ? ===Add the class in a CSS stylesheet=== Now the class is created in a CSS stylesheet. <code>td.intervention_close { background-color: #FFE6E6 !important; } </code> This is a class for each cell, the <td> tag. The ''!important'' attribute is added to be sure that this information has precedence over all the others. It is better to add this class in a [http://xataface.com/documentation/how-to/custom_javascripts custom CSS stylesheet]. ===Remarks=== Beware that some versions of IE don't respect the background-color property on the <tr> tag, so it is probably better to write: <code> tr.intervention_close td { background-color: #FFE6E6; }</code> i.e. to apply the background color to the individual cells. en 0 DataGrid 32 DataGrid ==Xataface DataGrid Module== Created by Steve Hannah, [http://weblite.ca Web Lite Solutions Corp.] ===Synopsis=== The Xataface DataGrid module uses the Ext DataGrid component (http://extjs.com) to add an editable grid component to your Xataface application. [[toc collapse=0]] ===Requirements=== * PHP 4.3+ * MySQL 4.1+ * Xataface 0.8+ ===License=== This module is distributed with ExtJS 2.2, which is distributed under the GPL v 3 (http://extjs.com/products/license.php). In order to be compatible with the ExtJS license, this module is also distributed under the terms of the GPL v3 (http://www.gnu.org/copyleft/gpl.html). ===Demo Video=== <nowiki> <embed src="http://media.weblite.ca/lib/flvplayer.swf" width="640" height="500" bgcolor="#FFFFFF" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" flashvars="file=http%3A%2F%2Fs3.amazonaws.com%2Fweblite_media%2FDataGrid-640x480.flv&image=http%3A%2F%2Fmedia.weblite.ca%2Ffiles%2Fphotos%2FDataGrid-640x480.flv.jpg&showdigits=true&autostart=false" /> </nowiki> ===Screenshots=== Click on image to enlarge <nowiki> <script language="javascript" type="text/javascript" src="http://media.weblite.ca/index.php?-action=gallery&-table=files&categories=8&-cursor=0&-skip=0&-limit=30&-mode=list&-photo_max_width=640&--format=js"></script> <div style="clear:both"> </div> </nowiki> ===Demo=== # LibrarianDB Demo: http://demo.weblite.ca/apps/librariandb/index.php?-table=books&-action=DataGrid_view , '''Log in with username "admin" and password "password"''' ===Download=== * [https://sourceforge.net/project/platformdownload.php?group_id=250381 DataGrid-0.2] * SVN Repository: http://weblite.ca/svn/dataface/modules/DataGrid ===Installation=== # Download and extract the DataGrid directory into your xataface/modules directory. # Add the following line to the [_modules] section of your application's [[conf.ini file]]:<code> modules_DataGrid=modules/DataGrid/DataGrid.php </code> # Ensure that your [[permissions]] are set up appropriately to allow your users to access the grid action (see next section). ===Setting Up Permissions=== This module defines the following [[permissions]]: * DataGrid:view_grid - Permission to view the data grid for a table. * DataGrid:create_grid - Permission to create a new data grid * DataGrid:edit_grid - Permission to edit an existing data grid * DataGrid:update - Permission to update records via the grid * DataGrid:manage_grids - Permission to access the datagrid control panel In order for a user to access/use the grid he must be granted at least the Datagrid:view_grid and DataGrid:update [[permissions]]. Both of these [[permissions]] are included in the following system roles by default: * EDIT * EDIT AND DELETE * DELETE * ADMIN * MANAGER And of course these [[permissions]] are included with the call to Dataface_PermissionsTool::ALL() . If you have assigned your own custom roles and want to enable access to the grid, you can simply add the following to your role definition in your [[permissions.ini file]]: <code> [MY ROLE] DataGrid:view_grid=1 DataGrid:update=1 </code> If you want to explicitly disable the grid for a role, you can extend the role and deny those same [[permissions]]: <code> [MY ROLE extends MY ROLE] DataGrid:view_grid=0 DataGrid:update=0 </code> ===Usage=== Once installed, log in as a user that has permission to access the grid. You should notice a new tab along with "details", "list", and "find", called "grid". Click on the "grid" tab to access the grid. You can double click on any field to edit it. Modified fields will be marked in red, and automatically saved every 5 seconds - after the changes are saved the field is no longer marked in red. ===Limitations=== Currently only fields with the following widget types are available to be edited in the grid: # text # textarea # select # date/datetime/time Other types of fields will simply not be included in the grid. ===Support/Questions=== Visit the Xataface forum at http://xataface.com/forum en 0 Drag_and_Drop_Reordering_of_Relationships 39 Drag_and_Drop_Reordering_of_Relationships ==Drag and Drop Reordering of Related Records in Xataface== One powerful aspect of Xataface is its abstraction of relationships between tables. Once you define a relationship users can browse related records, add new and existing related records, and delete related records to or from the relationship. For example, suppose you have a ''people'' table and a ''publications'', you could define a relationship from ''people'' to ''publications'' to identify publications that belong to a particular person. The table's might look something like: ===people table=== {| class="listing listing2" ! person_id ! person_name |- | 1 | John Smith |- | 2 | Ben Stein |- | 3 | Harley Davidson |- | 4 | Trevor Linden |} ===publications table=== {| class="listing listing2" ! publication_id ! owner_id ! pub_title |- | 1 | 2 | Introduction to widgetry |- | 2 | 2 | Intermediate Widgetry |- | 3 | 2 | Advanced Widgetry |- | 4 | 3 | How to play the violin |} See http://xataface.com/documentation/tutorial/getting_started/relationships for an introduction to relationships in Xataface, and how to define them. Our relationship definition in the ''people'' table's [[relationships.ini file]] might look something like: <code> [my_pubications] publications.owner_id="$person_id" </code> This indicates that any publication whose ''owner_id'' column matches the current ''people'' record's ''person_id'' field is considered part of the relationship. Using our example data above, this would mean that Ben Stein's ''my_publications'' relationship would contain 3 records: "Introduction to Widgetry", "Intermediate Widgetry", and "Advanced Widgetry". In our Xataface application this means that in the "Details" tab for the "Ben Stein" record, we would see a sub-tab ''My Publications'' which would contain a list of Ben Stein's publications. ===Adding Publication Order=== Now that we have our relationship, what if Ben Stein wants his publications to appear in a particular order whenever they are displayed to the user. Xataface allows us to specify an "order" column for our relationship, which will cause the related records to be orderable by drag and drop (if the user has appropriate permissions). # Add a field to the ''publications'' table named "pub_order" # Change the relationship definition in the people table's [[relationships.ini file]] to tell Xataface to use the pub_order field for sorting:<code> [my_pubications] publications.owner_id="$person_id" metafields:order="pub_order" </code> Now load up your application and navigate to the "My Publications" tab for the "Ben Stein" record. Now you're able to drag and drop rows in your application to reorder them. ===Permission to Reorder Records=== Only users who have been assigned the ''reorder_related_records'' permission for a record's relationship are allowed to reorder records of that relationship. By default the ''EDIT'' role contains this permission, as does any role that permits the user to edit the parent record of the relationship. The ''READ ONLY'' role does not contain this permission. If you want to explicitly deny this permission for all relationships in a record, you can simply set this permission to 0 in the associated role within your application's [[permissions.ini file]]: <code> [MY ROLE] reorder_related_records=0 </code> For more information about permssions see: * [[permissions.ini file|The Permissions.ini file reference]] * [http://xataface.com/documentation/tutorial/getting_started/permissions Introduction to Permissions] ===Loading Related Records using the Xataface API=== The ordering that is set via this drag and drop method is also honoured by the Xataface API when fetching related records. You can load related records using the [http://dataface.weblite.ca/getRelatedRecordObjects getRelatedRecordObjects] method of the [http://dataface.weblite.ca/Dataface_Record Dataface_Record] class. E.g. <code> $benStein = df_get_record('people', array('person_id'=>2)); $pubs = $benStein->getRelatedRecordObjects('my_publications'); foreach ($pubs as $pub){ echo $pub->val('pub_title').'<br/>'; } </code> This will list up to the first 30 publications of Ben stein in the order prescribed by our drag and drop ordering scheme. en 0 Dynamic_select_boxes 90 ==Dynamic select boxes== To create two select boxes whose one is dependent (slave) of the other (master), we need to use some javascript with Jason. Create the valuelists.ini: <code> ;valuelist for the slave [slaves_list] __sql__ = "select slave_id, slave_name, master_id from slaves" ; valuelist for the masters [masters_list] __sql__ = "select master_id,master_name from masters" </code> fields.ini: <code> [master] vocabulary=masters_list [slave] vocabulary=slaves_list </code> delegate class in the table directory : <code> ... function block__after_new_record_form(){ echo <<<END <script language="javascript"></script> END; } // Also place this javascript after an edit record form... function block__after_edit_record_form(){ return $this->block__after_new_record_form(); } </code> The 2.0 version has a [http://xataface.com/dox/modules/depselect/latest| depselect module] to produce cascading dynamic select boxes very simply. en encryption 29 encryption ==encryption [[fields.ini file]] directive== The '''encryption''' directive is meant to be used on password fields only. It specifies that a certain type of encryption is to be used in the storing of values in this field. For example, many PHP/MySQL applications use MD5 encryption to store their passwords. If you want your Xataface application to be able to use the same users tables, then you'll need to specify the '''encryption''' directive for the password field. ===Possible Values=== {| class="listing listing2" |- ! Value ! Meaning ! Version |- | md5 | MD5 encryption | 0.6 |- | sha1 | SHA1 encryption | 1.0 |- | encrypt | MySQL encrypt function | 1.0 |- | password | MySQL password encryption | 1.0 |} ===E.g. in the users table [[fields.ini file]]=== <code> [password] encryption=md5 </code> en 0 fieldgroup_template 51 fieldgroup_template ==Using a custom template for a field group on the edit form== [[toc]] Xataface allows you to partition your fields into ''groups'' so that similar fields are grouped together on the edit form. The default layout of the fields remains simply vertical, but you can customize this layout (on a per-group basis) by creating a custom template and then assigning this template to the field group with the ''template'' directive. ===Example=== For example, in your [[fields.ini file]] if you wanted to group your address fields together you might have: <code> [fieldgroup:address] label="Address Information" template="AddressInformationGroup.html" [address_1] group=address [city] group=address [state] group=address </code> Then you would add the a template named ''AddressInformationGroup.html'' to your application's ''templates'' directory to display how the fields are laid out: <code> <table width="100%"> <tr><th>Address 1:</th> <td>{$elements.address_1.html}</td> <th>City:</th> <td>{$elements.city.html}</td> <th>State:</th> <td>{$elements.state.html}</td> </tr> </table> </code> This would display all of the fields in this group in a single row (horizontally) instead of vertically. Note that this is an over-simplified example that doesn't take account for display error messages, required notices, grouped fields, and other information that you can obtain from the {$elements} array. en 0 fieldname__permissions 53 fieldname__permissions ==fieldname__permissions() method== [[toc]] The fieldname__permissions() methods will allow you to define custom permissions on a particular field in the [[delegate class]]. For example to specify permissions on a field named ''foo'' you would define the ''foo__permissions()'' method, and to define permissions on a field named ''role'' you would define the ''role__permissions()'' method. ==Example #1== (Note this example needs to be refined to be more clear) <code> function approval_level__permissions(&$record){ return array('edit'=>0); //this is will merge with what the permissions for the normal record } </code> Here we are targeting the ''approval_level'' field of the [[delegate class]]. The permissions method takes a return value an array of permissions. So for example: <code> $permissions['new'] = 0; $permissions['edit'] = 0; </code> Would be an example of an array of permissions which the key being the permission name and the value being a boolean to specify whether they have (1) or don't (0) have permissions to that field. We don't have to specify a complete array of permissions (ie. permission of edit, new, readonly, etc, etc), but rather only the ones we want specifically. The reason being that the permissions array in the return value gets merged with the permissions that this record normally gets from the record permissions. So if the record normally gives the permissions new=0, edit=1. Then the return value from approval_level will merge with the original permissions to produce an array like this: <code> $permissions['new'] = 0; $permissions['edit'] = 1; </code> === Also See: === * [[How_to_granulate_permissions_on_each_field]] * [[__field__permissions]] en 0 file 89 ==Dynamic select boxes== To create two select boxes whose one is dependent (slave) of the other (master), we need to use some javascript with Jason. Create the valuelists.ini: <code> ;valuelist for the slave [slaves_list] __sql__ = "select slave_id, slave_name, master_id from slaves" ; valuelist for the masters [masters_list] __sql__ = "select master_id,master_name from masters" </code> fields.ini: <code> [master] vocabulary=masters_list [slave] vocabulary=slaves_list </code> delegate class in the table directory : <code> ... function block__after_new_record_form(){ echo <<<END <script language="javascript"></script> END; } // Also place this javascript after an edit record form... function block__after_edit_record_form(){ return $this->block__after_new_record_form(); } </code> en filter 27 filter ==The filter attribute of the [[fields.ini file]]== The filter attribute with a value of 1 specifies that a field should be used as a filter field in list view. In list view, any filter fields will provide a select list with all of the possible values in that field. Selecting one of the items in this list will filter the results to only show records of that value. ===Example 1: Year, Make, Model=== The Fuel Economy Database has three fields with filter=1 : Year, Make, and Model. I.e., in their fields.ini file we have something like: <code> [Year] filter=1 [Make] filter=1 [Model] filter=1 </code> This causes 3 select lists to appear in list view. See the application [http://fueleconomydb.com/index.php?-action=list here] and notice the select lists for Year, Make, and Model just above the list of results. If you are filtering on a field where an ID is stored in the DB but you are using a vocabulary to associate it with a value, then it will still be sorted on the ID. If you want to sort on value then you should add a [[Grafted fields|grafted field]] with the value using the __sql__ directive of the fields.ini file, then use that grafted field as your filter field, like the following: <code> __sql__ = "select a.*, b.foo_name from a left join b on a.foo_id=b.foo_id" [foo_name] filter=1 </code> en 0 getFeed 42 getFeed ==getFeed() Delegate Class Method== [[toc]] ===Synopsis:=== The getFeed() method of a table [[Delegate class methods|delegate class]] or [[Application Delegate Class|application delegate class]] returns an associative array of parameters to configure the [[Introduction_to_RSS_Feeds_in_Xataface|RSS feed]] for a particular table . An RSS feed consists of the following components: # '''title''' - The title of the RSS feed as it should appear in the subscribers' feed list. # '''description''' - Describes the RSS feed. # '''link''' - A link to the RSS feed # '''syndicationURL''' - The URL to this RSS feed's site. ===Parameters=== # '''array''' $query - The HTTP query. Contains information like the current table, current action, and search parameters. This allows you to customize your RSS feed depending on the user's query parameters. ===Return Value=== The getFeed() method returns an associative array with the components of the RSS feed. This array does not need to contain all possible keys, or even any keys. Any keys that are omitted will simply use default values in the RSS feed. The array may contain the following keys: {| class="listing listing2" ! Name ! Description ! Version |- | title | The title for the RSS feed. If this omitted, it will try to use the ''title'' directive of the ''[_feed]'' section of the [[conf.ini file]]. Failing that, it will try to generate an appropriate title for the feed depending on the current query. | 1.0 |- | description | A Description for this RSS feed. If this is omitted, it will try to use the ''description'' directive of the ''[_feed]'' section of the [[conf.ini file]]. | 1.0 |- | link | A link to the source page of the RSS feed. If this is omitted, it will try to use the ''link'' directive of the ''[_feed]'' section of the [[conf.ini file]]. | 1.0 |- | syndicationURL | A link to the source page of the RSS feed. If this is omitted, it will try to use the ''syndicationURL'' directive of the ''[_feed]'' section of the [[conf.ini file]]. | 1.0 |} ===Example=== <code> function getFeed(&$query){ return array( 'title' => "RSS feed for the ".$query['-table']." table.", 'description' => "News and updates for automobiles", 'link' => df_absolute_url(DATAFACE_SITE_HREF), 'syndicationURL' => df_absolute_url(DATAFACE_SITE_HREF) ); } </code> '''Note that RSS feeds will work perfectly well without defining this method. This just allows you to customize one or more parameters of the RSS feed'''. ===See Also:=== * '''[[getFeedItem]]''' - A delegate class method available to both the [[Delegate class methods|table delegate classes]] to configure parameters for the particular items of the RSS feed. * '''[[getRelatedFeed]]''' - A [[Delegate class methods|delegate class method]] available to both the [[Application Delegate Class|application delegate class]] and the [[Delegate class methods|table delegate classes]] to configure the [[Introduction to RSS Feeds in Xataface|RSS feed]] for a related records list. * '''[[getRSSDescription]]''' - A delegate class method to override the description that appears for a particular record in an RSS feed. (The same as the ''description'' parameter of the [[getFeedItem]] method. * '''[[Introduction to RSS Feeds in Xataface]]''' - An overview of Xataface's RSS feed support. en 0 getFeedItem 41 getFeedItem ==getFeedItem() Delegate Class Method== [[toc]] ===Synopsis:=== The getFeedItem() method of a table [[Delegate class methods|delegate class]] returns an associative array of parameters for a record as it should appear as part of an [[Introduction_to_RSS_Feeds_in_Xataface|RSS feed]]. An RSS feed item consists of the following components: # '''title''' - The title of the record as it appears in the RSS feed. # '''description''' - The description of the record for the RSS feed. This is really the body of the RSS feed item. # '''link''' - The linkback URL if users want to know more about the record. # '''date''' - The date that the record was posted/modified. # '''author''' - The name of the person who posted this record. # '''source''' - URL to the site where record originated from. ===Parameters=== # '''Dataface_Record''' &$record - The record that is being represented in an RSS feed. ===Return Value=== The getFeedItem() method returns an associative array with the components of the RSS feed. This array does not need to contain all possible keys, or even any keys. Any keys that are omitted will simply use default values in the RSS feed. The array may contain the following keys: {| class="listing listing2" ! Name ! Description ! Version |- | title | The record title as it appears in RSS feeds. If this is omitted, the RSS feed will simply use the output of [http://dataface.weblite.ca/Dataface_Record Dataface_Record's] [http://dataface.weblite.ca/getTitle getTitle()] method. | 1.0 |- | description | The record description. This is used in the main body of the RSS feed. If this is omitted, the RSS feed will use an HTML table that shows all of the field data in the record. This value can also be overridden using the [[getRSSDescription]] method of the delegate class. | 1.0 |- | link | The URL to this record. If this is omitted it just points to the ''view'' tab for this record. However you can direct it anywhere you like. When the user clicks on the "More Info" link in his RSS reader it will direct him to this link. | 1.0 |- | date | The date that this record was posted or last modified. This is the date that an RSS reader will use to decide if it has already loaded the record yet. If this is omitted it will try the [http://dataface.weblite.ca/Dataface_Record Dataface_Record's] [http://dataface.weblite.ca/getLastModified getLastModified()] method to obtain the last modified date of the record. Failing that, it will use [http://dataface.weblite.ca/Dataface_Record Dataface_Record's] [http://dataface.weblite.ca/getCreated getCreated()] method to try to obtain the creation date of the record. This date should be a unix timestamp. | 1.0 |- | author | The name of the user who posted this record. If this is omitted, then it will try to use [http://dataface.weblite.ca/Dataface_Record Dataface_Record's] [http://dataface.weblite.ca/getCreator getCreator()] method. Failing that, it will use the value of the ''default_author'' parameter in the ''[_feed]'' section of the [[conf.ini file]]. If that is not defined, then it simply uses the string "Site Administrator". | 1.0 |- | source | The source URL where the feed is to have originated. If none is specified, then it will use the value of the ''source'' parameter in the ''[_feed]'' section of the [[conf.ini file]]. Failing that, it will simply use the URL to the application. Note that you can alternatively define this value using the [[getFeedSource]] method. | 1.0 |} ===Example=== <code> function getFeedItem(&$record){ return array( 'title' => "News Item: ".$record->getTitle(), 'description' => $record->display('News Body'), 'link' => $record->getPublicLink(), 'date' => strtotime($record->val('last_modified')), 'author' => $record->val('posted_by'), 'source' => 'http://www.example.com' ); } </code> '''Note that RSS feeds will work perfectly well without defining this method. This just allows you to customize one or more parameters of the RSS feed'''. ===See Also:=== * '''[[getFeed]]''' - A delegate class method available to both the [[Application Delegate Class]] and the [[Delegate class methods|table delegate classes]] to configure the RSS feed as a whole (not just for an individual item in the RSS feed. * '''[[getRelatedFeed]]''' - A [[Delegate class methods|delegate class method]] available to both the [[Application Delegate Class|application delegate class]] and the [[Delegate class methods|table delegate classes]] to configure the [[Introduction to RSS Feeds in Xataface|RSS feed]] for a related records list. * '''[[getRSSDescription]]''' - A delegate class method to override the description that appears for a particular record in an RSS feed. (The same as the ''description'' parameter of the [[getFeedItem]] method. * '''[[Introduction to RSS Feeds in Xataface]]''' - An overview of Xataface's RSS feed support. en 0 getRegistrationActivationEmailInfo 17 getRegistrationActivationEmailInfo ==getRegistrationActivationEmailInfo() Hook== A hook that can be implemented in the [[Application Delegate Class]] or the [[Table Delegate Class]] to override the default information that is used to send the registration activation email (the email that the user receives when they register). This should return an associative array with the keys: * subject - The subject of the activation email. * message - The message body of the activation email. * parameters - The parameters to be used in the mail() function for the activation email. * headers - The headers to use in the mail() function for the activation email. ===Signature=== function getRegistrationActivationEmailInfo( Dataface_Record &$record, string $activationURL ) : array ====Parameters==== {| class="listing listing2" ! Name ! Description |- | &$record | A Dataface_Record object encapsulating the record that is being inserted in the users table for this registration. |- | $activationURL | The URL where the user can go to activate their account. |- | returns | Mixed. If this method returns a PEAR_Error object, then registration will fail with an error. |} ===Example=== <code> <?php class conf_ApplicationDelegate { function getRegistrationActivationEmailInfo(&$record, $activationURL){ return array( 'subject' => 'Welcome to the site.. Activation required', 'message' => 'Thanks for registering. Visit '.$activationURL.' to activate your account', 'headers' => 'From: webmaster@example.com' . "\r\n" . 'Reply-To: webmaster@example.com' . "\r\n" . 'X-Mailer: PHP/' . phpversion() ); } } </code> ===Example 2: Only override the subject=== <code> <?php class conf_ApplicationDelegate { function getRegistrationActivationEmailInfo(&$record, $activationURL){ return array( 'subject' => 'Welcome to the site.. Activation required' ); } } </code> ===See Also=== * [[beforeRegister]] * [[afterRegister]] * [[validateRegistrationForm]] * [[sendRegistrationActivationEmail]] * [[getRegistrationActivationEmailSubject]] * [[getRegistrationActivationEmailMessage]] * [[getRegistrationActivationEmailParameters]] * [[getRegistrationActivationEmailHeaders]] en 0 getRegistrationActivationEmailMessage 19 getRegistrationActivationEmailMessage ==getRegistrationActivationEmailSubject() Hook== A hook that can be implemented in the [[Application Delegate Class]] or the [[Table Delegate Class]] to override the default registration activation email message body (the email that the user receives when they register). ===Signature=== function getRegistrationActivationEmailSubject( Dataface_Record &$record, string $activationURL ) : string ====Parameters==== {| class="listing listing2" ! Name ! Description |- | &$record | A Dataface_Record object encapsulating the record that is being inserted in the users table for this registration. |- | $activationURL | The URL where the user can go to activate their account. |- | returns | Mixed. If this method returns a PEAR_Error object, then registration will fail with an error. |} ===Example=== <code> <?php class conf_ApplicationDelegate { function getRegistrationActivationEmailInfo(&$record, $activationURL){ return 'Thanks for registering. Please visit '.$activationURL.' to activate.'; } } </code> ===See Also=== * [[beforeRegister]] * [[afterRegister]] * [[validateRegistrationForm]] * [[sendRegistrationActivationEmail]] * [[getRegistrationActivationEmailInfo]] * [[getRegistrationActivationEmailSubject]] * [[getRegistrationActivationEmailParameters]] * [[getRegistrationActivationEmailHeaders]] en 0 getRegistrationActivationEmailSubject 18 getRegistrationActivationEmailSubject ==getRegistrationActivationEmailSubject() Hook== A hook that can be implemented in the [[Application Delegate Class]] or the [[Table Delegate Class]] to override the default registration activation email subject line (the email that the user receives when they register). ===Signature=== function getRegistrationActivationEmailSubject( Dataface_Record &$record, string $activationURL ) : string ====Parameters==== {| class="listing listing2" ! Name ! Description |- | &$record | A Dataface_Record object encapsulating the record that is being inserted in the users table for this registration. |- | $activationURL | The URL where the user can go to activate their account. |- | returns | Mixed. If this method returns a PEAR_Error object, then registration will fail with an error. |} ===Example=== <code> <?php class conf_ApplicationDelegate { function getRegistrationActivationEmailInfo(&$record, $activationURL){ reeturn 'Welcome to the site.. Activation required'; } } </code> ===See Also=== * [[beforeRegister]] * [[afterRegister]] * [[validateRegistrationForm]] * [[sendRegistrationActivationEmail]] * [[getRegistrationActivationEmailInfo]] * [[getRegistrationActivationEmailMessage]] * [[getRegistrationActivationEmailParameters]] * [[getRegistrationActivationEmailHeaders]] en 0 grid 67 grid ==widget:type = grid== Suppose we have two tables, tbl_organisation and tbl_individuals, in the edit view for a record in the organisations table (tbl_organisations) we also want to be able to view and edit the individuals within this organisation we can use widget:type=grid In the /tables/tbl_organisation/fields.ini we create a transient field by adding: <code> [Individuals] widget:label = "Individuals" transient=1 relationship=individuals widget:type=grid widget:columns="ind_firstname,ind_lastname,ind_tel" </code> The above assumes we have a relationship entry in our /tables/tbl_organisation/relationships.ini that looks like this: <code> [individuals] __sql__ = "SELECT * FROM tbl_individual WHERE org_id='$org_id'" </code> The fields.ini will show the three columns shown in widget:columns from the table tbl_individual Correct permissions need to be set to enable editing and deletion etc of these records. en 0 group 28 group ==group directive in [[fields.ini file]]== The group directive allows you to declare that certain fields of your table should be grouped together on the edit form and the view tab (and other logical places). For example, fields like address, city, state, country, postal_code would likely be grouped together as address_info. Grouping the fields together will make the fields appear in a section of their own in the view tab and the edit form. E.g. In your fields.ini file: <code> [address] group=address_info [city] group=address_info [state] group=address_info [country] group=address_info [postal_code] group=address_info </code> ===Configuring the Group as a Whole=== You can also configure your group in the fields.ini file by adding a '''fieldgroup:NAME''' section, where '''NAME''' is the name of the group. E.g. <code> [fieldgroup:address_info] label="Address Information" description = "Please enter your address information below" </code> ====See also:==== * [[fields.ini file]] - Scroll down to the '''Field Groups''' section. en 0