Demo of application, parts to be submitted for vote

From: Date: Fri, 12 Sep 2003 15:05:20 +0000
Subject: Demo of application, parts to be submitted for vote
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21439@lists.php.net to get a copy of this message
I submitted a package description for feedback the other day, and several people asked that they see an example of what it does, so a link to the app as it stands follows. It it currently written on top of PHPLib and I am looking at converting and submitting several modules. Also, several people asked what the difference was between this and the DB_DataObject objects. They are designed for opposing goals. The DB_DataObject is written for a structured environment where the data design can be specified by the developer and objects build in code and business rules developed in code. My objects are designed around an ad hock environment where the data structure is defined by the database and not committed to code. Where selecting or modifying a record is not tied to a table, but to the information that needs to be presented and edited independent of where is comes from. That said, DB_DataObject may be able to be modified to work in both environments. If the community is interested in the ad hock aspects, I will look into that and make a recommendation for comment. http://www.restaurantamerica.com/admin/. Click on the Forms link. Here is a description of what is going on: First, there is a page generation engine. It takes a template that does nothing more than set up the HTML page (http://www.restaurantamerica.com/structures/common/admin.tpl) and places the content on it as defined from the database. Each HTML tag has an associated object that can render that table. For instance, there are table, table row, table data, and img objects. Some of these objects are extended. For instance, the image object has been extended to work within an image gallery subsystem. In this case, the database specifies that the content is a form object, which it intantiates. The form object is responsible for drawing the specified forms, then responding to the user action when the form has been submitted. Action conditions and actions are specified in the database and can be viewed by drilling down into the form maintanance that is on the screen. There are two types of forms. Lists are read only forms that call the report subsystem to simply list out the data. AddEdit actually allows you to make changes to data. The database specifies that the form is number 3 (as you can see from the list) and tells the form object to draw number 3. The form object looks into the database for information about form number 3 and finds that it is a List. The columns that are desired and default filter are read from the database. This information is passed to the report subsystem. The report subsystem passes the list of columns and filters to the DBCatalog object to build the select statement that retreives the data. It passes the built select statement to the selector object. Then it calls the renderer object to step through the data and render it. When a button is clicked and the form submitted, the submitted data is processed by the forms subsystem and defined actions taken. So, the modules that I am asking about interest in: HTML_Page_Renderer - that uses a combination of HTML Templates and Content Rendering objects to render an HTML page HTML_Page_Renderer_Config HTML_Page_Renderer_Config_SQL will read the required information from a SQL compliant database HTML_Page_Renderer_Config_LDAP, _TEXT, _CONFIG, _* will read the required information from other data sources HTML_Page_Renderer_Element HTML_Page_Renderer_Element_Table, _Table_Row, _Table_Data, _Image, _* are the objects that actually render the tags HTML_Form_Renderer - will render an HTML form using the Form building classes (HTML_Quickform) and take defined actions to submitted data. HTML form also maintaines a form excecution stack so that you can jump to previous forms if needed. HTML_Form_Renderer_Config HTML_Form_Renderer_Config_SQL will read the required information from a SQL compliant database HTML_Form_Renderer_Config_LDAP, _TEXT, _CONFIG, _* will read the required information from other data sources (to be delevoped) HTML_Form_Action - code to perform the specified action HTML_Form_Action_Save HTML_Form_Action_Go HTML_Form_Action_Back HTML_Form_Action_Set_Filter HTML_Form_Action_Clear_Filter HTML_Form_Action_Set_Element_Default HTML_Form_Action_Set_Element_Absolute Report - will render a report using the specified selector and renderer Report_Selector Report_Selector_SQL Report_Selector_LDAP Report_Renderer Report_Renderer_HTML Report_Renderer_PDF, _XML, _* DBCatalog - Skeleton for interacting with a Data source DB_Catalog_Config DB_Catalog_Config_SQL - store the catalog in a sql data source DB_Catalog_Config_LDAP, Config, _* DB_Catalog_Build DB_Catalog_Build_SQL - Build SQL compliant Select, Insert, Delete, Update Statements DB_Catalog_Build_LDAP, Config, _* Thanks, Rob

« previous php.pear.dev (#21439) next »