Re: New HTML or Maintain DB class needed?

I've been looking at a similar thing. I was writting a web based database application. It was looking like 2 common patterns were emerging. Creating a list of records, and a dialog that would allow you to add/display/edit/delete a record. I would write one php page to list selected records, and have refs that would point off to a page that would edit that record. The list page was pretty simple. The record page seemed to follow the pattern (this is from memory and somethat generalized, so forgive any discrepancies): If delete, drop record. If [add|modify] record, verify the data. If verified, If add record, insert record If modify, update record send OK response and exit else mark rejected fields if new, set defaults if new|modify if new|modify, create form and exit if display display record All field information (data type, display type, verification rules, SQL names, post tags, attributes, etc.) are maintained in a list of objects. There are generalized routines to verify, display, insert, etc. This way the objects become extensible by subclassing them. Throw in a class to display the objects in a table, and you can generate a very robust web page with just a few statements. Then the next step is to create a WSYIWYG editor to define these objects. I've gone through 2 passes at prototypes, but my schedule has gotten full of late. --- Stefan Fountain <stefan.fountain@eight.nl> wrote: > For those of you willing to have a look at this I am wondering how and > if > creating this new class is useful so please give some feedback as to > the > architecture and use of such a class. Any feedback is welcome let me > know if > there are known classes that already address the issues my 'new' class > will > try to solve. > > Thanks for your help/feedback, > Stefan Fountain > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > I've been looking at creating a new class with the main purpose of > being the > core section of a CMS that edits tables. I'm wondering if it is wise to > extend an existing class or make a new one. There are a lot of DB > classes > already in the PEAR and one more might cause some confusion (if even it > gets > added to PEAR) I would like to discuss the possibility to add > functionalities to existing PEAR classes or if necessary indeed create > a new > one. Maybe there already is a DB class (or another class) that holds > the > functions I want but could not find it in the PEAR browser. In a sense > my > class is a HTML interface to edit DB tables. > > An example of how such a class could look like : > > > Description: > Class that will get defined fields from a db table and return them in > an > HTML list with the possibilities to edit or delete. The list will show > an > add function as well. Edit will return a form with the specified record > and > validate upon submit (maybe using PEAR::Quick_Form?) Add will do the > same > but with blank fields. It would work similar to a script that uses a > $cmd > variable to switch between commands (list, edit, add, delete). The > class > would return HTML to the script that calls it, optionally this could be > extended in the future to deliver XML feeds of database results or > whatever. > > > Class attributes: > > Db connection parameters > array->(db_host, db_name, db_user, db_passw) > > Table parameters > array->(table_name, array(table_fields, table_field_types), > key_field) > > HTML Templates > array->(list_template, edit/add template, delete_template) > > (Also 'private' attributes like item_from_db_array etc.) > > Class methods: > Constructor($cmd) // switches between wanted command > List_items() // calls db and lists items in local array > Add_new_item() // does as the name implies > Edit_specific_item() // does as the name implies > Delete_specific_item() // does as the name implies > > Obviously there will have to be get and set methods as well as a good > way of > setting up the interaction between different methods (for example edit > being > the same as add but with default values returned from db) > > > That's the idea. > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > ===== --- Wayne Johnson, | There are two kinds of people: Those 3943 Penn Ave. N. | who say to God, "Thy will be done," Minneapolis, MN 55412-1908 | and those to whom God says, "All right, (612) 522-7003 | then, have it your way." --C.S. Lewis __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com