Demo of application, parts to be submitted for vote
| From: | Rob Hutton | 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