Date: 12/12/99
- Next message: 318417LD <email protected>: "[PHPLIB] Save Up To 75% on International Calling"
- Previous message: Martin Decker: "[PHPLIB] variable variables as object names"
- In reply to: David Nind: "[PHPLIB] OOH Forms - extending for editing or deleting data"
- Next in thread: Massimiliano Masserelli: "Re: [PHPLIB] OOH Forms - extending for editing or deleting data"
- Reply: Massimiliano Masserelli: "Re: [PHPLIB] OOH Forms - extending for editing or deleting data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Nind wrote:
>
> I was wondering if anyone has extended OOH Forms for editing and deleting database information.
Not really. Have a look at: http://projektordner.dev.netuse.de/.
It's an attempt to join template and oohforms. It's easy to use
db->metadata() and the new stuff to display a database table as a
form. But I'm afraid we should not go this way any further.
There thoughts about a complete rewrite of oohforms. Validation
for example is not very helpful. To provide ooh_to_tpl() with a
validate() function such as in oohform I have to cache all form
elements, build the form, validate it, get the validation result,
drop the form and rebuild it using the validation results just to
set an error flag in front of some elements... No comment on
that. As you probably have read others have problems using the
javascript validation.
In my opinion we should drop all the template stuff (oohform,
tpl_table and ooh_to_tpl) and go for a complete rewrite. We have
three major tasks:
a.) new oohforms
A class that generates form elements, quite similar to what's
does oohforms today. It does:
- server side validation inline (such as oohform->validate())
- generates PHP code for server side valdation()
- generate JavaScript code for client side validation
- it's possible to write validators for a single element
The internal structure follows the needs of b.)
b.) connection between LDAP/SQL and new oohforms
The abstraction level must be above SQL requests.
c.) displaying forms
Eighter something like tpl_form (which I have never used and
can't comment on) or a wrapper between oohform and template. I
personally would vote for the second. Ususally a form has a
simple one column layout. It's easy to generate such if form with
an template. tpl_form allows you to generate multi column forms.
But I really doubt that's it is very efficent to write lots of
php code to generate a multi column form. I would write my
personal form to n-column layout wrapper to save overhead.
Will I do all the work? No, I won't.
Ulf
-- Ulf Wendel NetUSE Kommunikationstechnologie GmbH Siemenswall, D-24107 Kiel, Germany Fon: +49 431 386435 00 -- Fax: +49 431 386435 99 - PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>. To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in the body, not the subject, of your message.
- Next message: 318417LD <email protected>: "[PHPLIB] Save Up To 75% on International Calling"
- Previous message: Martin Decker: "[PHPLIB] variable variables as object names"
- In reply to: David Nind: "[PHPLIB] OOH Forms - extending for editing or deleting data"
- Next in thread: Massimiliano Masserelli: "Re: [PHPLIB] OOH Forms - extending for editing or deleting data"
- Reply: Massimiliano Masserelli: "Re: [PHPLIB] OOH Forms - extending for editing or deleting data"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

