Page 1 of 2
Form Library
Posted: Mon Oct 09, 2006 8:00 pm
by Ollie Saunders
OK I've finished the UML for my forms library. Now, I want to interogate it. Will my design stand up to the desires of a community? Oh look, here's a community
Basically what I'm after is for you guys to tell me what you would like to see in a forms library for PHP 5 and I'll take heed. So the perfect forms library would be able to do what? Your chance to bitch
Also mention issues of design as well if you like. For example I want to be able to create a widget by doing this ... with some example code etc.
Re: Form Library
Posted: Tue Oct 10, 2006 3:17 am
by Chris Corbyn
ole wrote:So the perfect forms library would be able to do what?
Make forms

Re: Form Library
Posted: Tue Oct 10, 2006 4:56 am
by jmut
ole wrote:OK I've finished the UML for my forms library. ...
Where is it?
Posted: Tue Oct 10, 2006 5:21 am
by Chris Corbyn
Off the top of my head:
- Organised fields and labels
- Custom CSS
- Form <--> SQL
- Pluggable/extendable validation on both client and server
- Pretty errors
- Required fields (ties in with validator)
- Bot prevention
- Ability to set client-side events (DHTML) for individual fields
- (Possibly) some kind of markup/template support
Re: Form Library
Posted: Tue Oct 10, 2006 6:17 am
by Ollie Saunders
jmut wrote:ole wrote:OK I've finished the UML for my forms library. ...
Where is it?
Its only rough, I doubt it would mean anything to anyone but myself.
# Organised fields and labels
How would you like to see this done?
# Custom CSS
You write your own, none is generated, basic templates will probably be bundled. How would you like to see this done?
# Form <--> SQL
You can use or, if necessary, write your own postprocessor which can do anything you like to field input. Most of the time it'll just be SQL escaping. How would you like to see this done?
Pluggable/extendable validation on both client and server
Server only at this stage. You write your own assertions or use conventional logic to add errors in onSubmit events. The events are obviously totally within your control so you can attach them to individual fields, whole forms, interchange them, extend them. A test class is provided to make testing for common things easy. How would you like to see this done?
# Pretty errors
Errors appear in a separate div above the entity in question (you can change this if you wish) you can apply whatever CSS you like. The errors messages are written by yourself to ensure user friendlyness. How would you like to see this done?
# Required fields (ties in with validator)
I was thinking of leaving this to be done manually with the onSubmit events but I might actually make required a fixed property of fields.
# Bot prevention
No support as yet. I'll definately think about this. How would you like to see this done?
# Ability to set client-side events (DHTML) for individual fields
Supported. How would you like to see this done?
# (Possibly) some kind of markup/template support
How do you mean?
Posted: Tue Oct 10, 2006 6:33 am
by volka
What problems of existing frameworks will it adress?
Posted: Tue Oct 10, 2006 6:50 am
by Ollie Saunders
Main:
- Give developers the tools they need to build user interfaces of web application level complexity.
- Provide as much control and flexibilty as resonable.
- Encourage users of the library to follow good standards:
- Flexibility
- Reusability
- Security awareness
- Character encoding awareness (UTF-8 support built-in)
- Compartmentalization (separation of roles)
- Keep it simple
- Reduce the workload required to build good quality web interfaces
- Focus on user interface quality
Some notible policies:
- HTML is encapulated, most of the time you will never have to think about it as output is handled by a completely separate set of objects.
This way:- You can't get it wrong, output will always be XHTML valid
- You are forced to use CSS for styling
- You can write completely different output system if you like, for PDF for example
- PHP 5 only
- Validation isn't generated so you write custom errors.
Posted: Tue Oct 10, 2006 7:32 am
by Chris Corbyn
I'm not really getting it. So do you draw the form yourself or does this library do it?
Do you have a use case example?
EDIT |
old wrote:You can't get it wrong, output will always be XHTML valid
And if I was using HTML as a doctype?
Posted: Tue Oct 10, 2006 8:43 am
by Ollie Saunders
I'm not really getting it. So do you draw the form yourself or does this library do it?
Library does it.
Do you have a use case example?
Nope I'm starting on the documentation today and implementation later.
And if I was using HTML as a doctype?
XHTML is backwards compatible. My library doesn't generate the doctype you supply that yourself.
Posted: Tue Oct 10, 2006 9:01 am
by Chris Corbyn
ole wrote:I'm not really getting it. So do you draw the form yourself or does this library do it?
Library does it.
Do you have a use case example?
Nope I'm starting on the documentation today and implementation later.
And if I was using HTML as a doctype?
XHTML is backwards compatible. My library doesn't generate the doctype you supply that yourself.
XHTML is not backwards compatible if you're following standards. <br /> will not validate in HTML. You'll need to build your library to be informed of the doctype being used

AC did this with HTMLPurifier.
Posted: Tue Oct 10, 2006 1:50 pm
by patrikG
also, scaffolding is always nice

Posted: Tue Oct 10, 2006 3:55 pm
by Ollie Saunders
What's that?
Posted: Tue Oct 10, 2006 3:59 pm
by Christopher
Is this an HTML generator or a Form Conroller?
Posted: Tue Oct 10, 2006 4:09 pm
by Ollie Saunders
It generates HTML, but you could write another renderer to generate anything you wish.
What's a form controller?
Posted: Tue Oct 10, 2006 4:10 pm
by Luke
A form controller would allow multi-page forms... it would behave like any other controller, except scaled down to a form (right arborint?)