Re: Demo of application, parts to be submitted for vote

It still sounds interesting.. - although a bit of advice on proposals here... - focus on presenting the code. (eg. links to phps.) - try not to write too long explainations, alot of us are very lazy - any email over 3 paragraphs gets flagged as to-read later.. (or never...) - try to show simple usage examples.. - we cant download / comprehend huge applications in one go.. - or make decission on them.. == and hence.. try not to mix multiple packages into one email.. Have a look at Stephans proposal - http://www.php-tools.de/PEAR/XML_Statistics/ It's a good example... (perhaps we should copy that to somewhere on pear.php.net as a 'best practice' :) Regards Alan Rob Hutton wrote:

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

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com