RE: [PEAR-DEV] Demo of application, parts to be submitted for vote

This was not a package proposal. The email I sent the other day was about just the DBCatalog portion, not mixing multiple packages, and despite a description of the difference between having a "structured environment" with the DB_DataObject and an "ad hock" one, I got almost exactly your comment, "Sounds interesting, but I'm not sure I understand what it does." So here is what it does. If the group is interested in having an "ad hock" environment to supplement the "structured" then I will migrate in a way that will fit in with Pear. Otherwise, I am not going to worry about it.... Thanks, Rob > -----Original Message----- > From: Alan Knowles [mailto:alan@akbkhome.com] > Sent: Friday, September 12, 2003 11:03 PM > To: Rob Hutton > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] 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 > >