I spent the weekend to write a component, that should solve my problem. It 
took a bit longer, because I initially made it way to complicate (validator 
classes, visitor pattern).
It's intentionally restricted to handle only HTML forms and only for the 
validation part. Trying to handle anything more will inevitable lead to 
overcomplex crap, IMHO.
Now I'm putting it to work in a rather complex form. Would be happy to get 
your feedback. If there's interest, we could s/ymc/ezc/ it.

http://github.com/thkoch2001/ymc-htmlform/tree/master

Best regards,

Thomas Koch


> Thomas Koch a écrit :
> > Hi,
> >
> > the rating of the UserInput component vary between "not as good as it
> > could be" and "stinky crap".
> > Since I need to handle a rather complicate form now, I start implementing
> > an "HtmlForm" component on my own. It's aim is to solve my problem at
> > hand in a matter of hours, but I'd be happy, if it could become the
> > prototype of a new form handling component in ezc.
> >
> > My (incomplete) notes so far:
> >
> >
> >
> > Other PHP Projects with Form handling components
> > ================================================
> >
> > Interesting
> > -----------
> >
> > - Agavi: AgaviValidator
> >   http://www.agavi.org/
> >   interesting
> >
> > - Codeigniter
> > http://codeigniter.com/user_guide/libraries/form_validation.html
> >
> > - Symfony
> > http://www.symfony-project.org/forms/1_2/en/
> >
> > Not so interesting
> > ------------------
> >
> > - http://phpfuse.net/wiki/index.php?title=API:FuseFormValidator
> >
> > Crap
> > ----
> >
> > - ZF.
> >
> > - CakePHP: One class FormHelper
> >
> > - kohanaphp
> >  
> > http://dev.kohanaphp.com/projects/formo/repository/browse/trunk/libraries
> > CRAP
> >
> > Requirements
> > ============
> >
> > - Testable with PHPUnit
> >
> > - Validation can depend on multiple elements
> >
> > - Custom Validators can be added
> >
> > - Form objects can be used
> >
> >   - inside a template to mark erroneous fields
> >
> >   - in a system like eZ Publish, where a form is build from many
> >     datatypes
> >
> >   - in the controller to get quick access to validated user input
> >
> > - Element Groups can be reused in different forms
> >
> > - The component doesn't help in building the form.
> >
> > - Forms can be represented as PHP classes:
> >   $regForm = new myAppRegistrationForm
> >
> > - A form consists of a root Element Group which contains Elements or
> >   other Element Groups. The resulting Graph can be visited
> >
> > - All Classes can be replaced by other implementations, since checks are
> >   done against interfaces.
> >
> >
> > Design
> > ======
> >
> > Interfaces
> > ----------
> >
> > inputsource
> > ^^^^^^^^^^^
> >
> > abstracts access to POST/GET to ease Unit Testing
>
> Not only that, but we could swap out the html form with a REST / xmlrpc
> call and, provided that param names are the same, carry out the same
> validation.
> That is, hardcode as little dependency on html conventions as possible
> in this class...
>
> > hasData
> > getFilteredInput( $elementName, $filterId, array( 'options' =>
> > $inputElement-
> >
> >> options, 'flags' => $flags ) )
> >
> > form
> > ^^^^
> >
> > ButtonElement getButton()
> > setButton( ButtonElement )
> > ElementGroup elements
> >
> > interface parsable
> > ^^^^^^^^^^^^^^^^^^
> >
> > parse( $form, $inputSource )
> >
> >   parses input and sets values / error information
> >
> > isValid
> >
> >
> > interface ElementGroup
> > ^^^^^^^^^^^^^^^^^^^^^^
> >
> > implements parsable
> > implements visitable
> >
> > getElements
> > addElement
> > getElementByName
>
> I suppose that if I have a form where user needs to fill out element
> group A OR element group B I could do that easily with one elementgroup
> that has 2 subgroups?
>
> > interface Element
> > ^^^^^^^^^^^^^^^^^
> >
> > implements parsable
> > implements visitable
> >
> > properties
> >
> > requiredPresent
> > requiredNonEmpty
> > value
> > htmlName
> > htmlType
>
> see above. Why not Name / Type here?
>
> Plus I think we could add more info to forms elements to ease html
> rendering (description, title and so on)? Maybe via a new interface?
>
> > validator
> >
> > interface Validator
> > ^^^^^^^^^^^^^^^^^^^
> >
> > The validator is optional or can be a proxy validator to group several
> > validators.
> > First validation is done by the filter extension.
> >
> >
> >
> >
> >
> >
> > Thomas Koch, http://www.koch.ro
Thomas Koch, http://www.koch.ro
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Reply via email to