I figured out why I'll never be happy w/ php forms libraries

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Kieran Huggins »

arborint wrote:I believe that I ended up actually implementing (almost) everything that you requested. There is a setModel() method that provides the data to the form fields. It can be a Model or the Request as I recall.
Sweet! I'll have to check it out :-)
arborint wrote:Yes. The thing I am interested in is what data or Javascript the form code would need to generate to make the client and server code work together. And we have not even broached Ajax forms or fields.
The form controller would just need to embed some validation rules in xhtml attributes, a regex would probably suffice. For any extra client side validation you could simply run an ajax request that simulates the submission and returns errors from the server-side model validation (for duplicate keys, etc...)

Once the validation regexen exist in the xhtml attributes, a simple (non-dynamic) jquery method could be used to validate the format of the data.
arborint wrote:I saw. Actually Matthijs and I have been doing the same project, so we may have an apples and apples comparison soon. ;)
ooooooh.... SHOWDOWN! :rofl:
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Christopher »

Kieran Huggins wrote:The form controller would just need to embed some validation rules in xhtml attributes, a regex would probably suffice. For any extra client side validation you could simply run an ajax request that simulates the submission and returns errors from the server-side model validation (for duplicate keys, etc...)
I think you can generate that kind of thing right now. If you use the alternate syntax of passing an array, you can add any attributes you want:

Code: Select all

$form = new A_Html_Form();
$form->text(array('name'=>'blogPost[title]', 'val:regex'=>'\w{1,255}'));
$form->textarea(array('name'=>'blogPost[body]', 'val:regex'=>'\w{1,65535}'));
$form->submit('submit', 'login');
echo $form->render();
 
You will get:

Code: Select all

<form method="post" action="/posts/new">
  <input type="text" name="blogPost[title]" val:regex="\w{1,255}" />
  <textarea name="blogPost[body]" val:regex="\w{1,65535}"></textarea>
  <input type="submit" />
</form>
Kieran Huggins wrote:ooooooh.... SHOWDOWN! :rofl:
OH YEAHHHHH BABY!!!!! :rofl:
(#10850)
User avatar
Kieran Huggins
DevNet Master
Posts: 3635
Joined: Wed Dec 06, 2006 4:14 pm
Location: Toronto, Canada
Contact:

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Kieran Huggins »

arborint wrote:
Kieran Huggins wrote:The form controller would just need to embed some validation rules in xhtml attributes, a regex would probably suffice. For any extra client side validation you could simply run an ajax request that simulates the submission and returns errors from the server-side model validation (for duplicate keys, etc...)
I think you can generate that kind of thing right now. If you use the alternate syntax of passing an array, you can add any attributes you want:

Code: Select all

$form = new A_Html_Form();
$form->text(array('name'=>'blogPost[title]', 'val:regex'=>'\w{1,255}'));
$form->textarea(array('name'=>'blogPost[body]', 'val:regex'=>'\w{1,65535}'));
$form->submit('submit', 'login');
echo $form->render();
 
You will get:

Code: Select all

<form method="post" action="/posts/new">
  <input type="text" name="blogPost[title]" val:regex="\w{1,255}" />
  <textarea name="blogPost[body]" val:regex="\w{1,65535}"></textarea>
  <input type="submit" />
</form>
er.... whats the point of that? 233 characters in PHP replaces 213 characters in xhtml... and the generator isn't filling in any of the values. Am I missing the point? Or is it?
arborint wrote:
Kieran Huggins wrote:ooooooh.... SHOWDOWN! :rofl:
OH YEAHHHHH BABY!!!!! :rofl:
Oh, it's SOOOO ON!
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Christopher »

Kieran Huggins wrote:er.... whats the point of that? 233 characters in PHP replaces 213 characters in xhtml... and the generator isn't filling in any of the values. Am I missing the point? Or is it?
If you add the following (2nd line) it will fill in the values:

Code: Select all

$form = new A_Html_Form();
$form->setModel($model);
$form->text(array('name'=>'blogPost[title]', 'val:regex'=>'\w{1,255}'));
$form->textarea(array('name'=>'blogPost[body]', 'val:regex'=>'\w{1,65535}'));
$form->submit('submit', 'login');
echo $form->render();
The Model can be an array or an object with a get() method.
Kieran Huggins wrote:Oh, it's SOOOO ON!
:mrgreen:
(#10850)
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Re: I figured out why I'll never be happy w/ php forms libraries

Post by jmut »

I read the whole thread so far.... I don't see anything Zend_Form cannot do at this point. I think it adds the most flexibility possible (from stuff described).
You can redner html anyway you want...you have access of form elements and all in controller.... can easily attach validators,filters to elemnt/form and all, tottally interchangable....can do all this city/zip in one line etc etc....
I really don't see the drawback of Zend_Form at this point.
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Re: I figured out why I'll never be happy w/ php forms libraries

Post by jmut »

Kieran Huggins wrote:....
er.... whats the point of that? 233 characters in PHP replaces 213 characters in xhtml... and the generator isn't filling in any of the values. Am I missing the point? Or is it?
....
Edit: Mm...it's more like 233characters in PHP replaces 2333 chars in xhtml
The point is you can use same code and just display it on some other view.
Else you end up either:
1. duplicate xhtml
2. have tons of small views that you include so you don't duplicate
3. You repeat code for practically same elements.

I personally do echo $this->form in the view and it builds all elements....You can do 2 or 3 (max) viewScripts if things are that bad and you need some really twisted custom render situation.

P.S. And designer sitution is not bad either...as only thing he has to know is class names of form, and some key elements inside... + error divs so can built the whole styling. Shouldn't need to mess with html
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: I figured out why I'll never be happy w/ php forms libraries

Post by onion2k »

The Ninja Space Goat wrote:Not only is form development the longest, most tedious portion of development, it's also one of the most important to get right.
... ... ...
Why is it so hard to find a good solution for this in PHP? I think it has a lot to do with the fact that PHP is just too damn verbose. From the definition of the form to the template that renders it, PHP just requires too much work.
Those two points appear to be contradictory to me. You understand it's the most important part of the site, and you want to take shortcuts in it? If I was your boss that would start sounding alarm bells in my head. Shortcuts in unimportant areas are fine. Shortcuts in important bits ... hell no.

If the code is for something vital then verbose is good.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: I figured out why I'll never be happy w/ php forms libraries

Post by matthijs »

Following along as well. I just want to say that Arborint is right that you can only have a useful discussion if you take one use case and then compare different solutions.

And then second, you have to look into different use cases, from a simple login form to a complex, 50 fields form with a lot of logic.

The thing is, for a default simple login form, the more automated echo $this->form() works ok. But if you have a large registration or shopping cart form, it's a completely different situation. And my feeling is that most of you guys are mainly programmers (no offense if you're not!) so are looking at this from a programmer's viewpoint. So you want to be able to do echo $this->form and be done with it. But the (graphic) designer or front-end guy will have a very hard time with that and might not accept that. Because he wants to design field 8, 16 and 23 just a bit different. And he wants to be able to add a small extra note with field 26. And have a slightly different behavior in field 4. Etc etc. Or he wants to add another fieldset around a few form fields. Now, does he have to go back to the programmer and ask the programmer to add a few extra lines to the RegistrationFormcontroller class? No. he should be able to just edit his template file. And maybe you think these issues are not important, but I think they are. As Ninja said, forms are an important part of the site/app. They are tedious for the user as well! So every small detail that improves that user experience will make a big difference. And that's why it's difficult to have a solution in which you just dump out those 40 fields in some standard html.

Anyway, that's just to say that, I think, first, you have to support multiple situations (automated code generating versus customizable template like) and second, that you have to clearly define the use cases if you want to compare apples to apples.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Christopher »

jmut wrote:I read the whole thread so far.... I don't see anything Zend_Form cannot do at this point. I think it adds the most flexibility possible (from stuff described).
You can redner html anyway you want...you have access of form elements and all in controller.... can easily attach validators,filters to elemnt/form and all, tottally interchangable....can do all this city/zip in one line etc etc....
I really don't see the drawback of Zend_Form at this point.
I think you might be right. I think Zend_Form may be the best thing around right now. But that leads to the question of whether better solutions are possible. Ninja tried it and was happy for a while, but now is looking for something better.

Perhaps you would like to present working Zend_Form code for different use cases and we can see if we can produce a better solution? Start with something simple and add complexity...
(#10850)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Christopher »

onion2k wrote:If the code is for something vital then verbose is good.
Yes and no. I agree that people need to accept that forms code is verbose, but I think it is the complexity of the problem not the importance that makes this so. I also noted the paradox you spotted. It is a common problem in build forms solutions and with people accepting forms solutions.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Re: I figured out why I'll never be happy w/ php forms libraries

Post by Maugrim_The_Reaper »

Seems a bit obscured but isn't the typical practice for a developer to whip up the simplest possible thing that works (i.e. use a forms library) and then wait for the designer to say "NOOOOoooo!" in an exasperated screech, shrug, and rework that specific area as needed? It's not really a paradox but just part of the process then.

I don't think I'm talking crap. :oops:
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: I figured out why I'll never be happy w/ php forms libraries

Post by matthijs »

Maugrim_The_Reaper wrote:Seems a bit obscured but isn't the typical practice for a developer to whip up the simplest possible thing that works (i.e. use a forms library) and then wait for the designer to say "NOOOOoooo!" in an exasperated screech, shrug, and rework that specific area as needed? It's not really a paradox but just part of the process then.

I don't think I'm talking crap. :oops:
Or the other way around. The designer comes up with a detailed design and specification of how the form must look and work. And then the programmer just has to swallow that and build it like that, no matter how tedious.

The thing is, this just shows the wildly different situations there are. Proces A, proces B, small form, big form, simple form, complex form. So again, let's figure out a few common use cases and start with those.
arborint wrote:Yes and no. I agree that people need to accept that forms code is verbose, but I think it is the complexity of the problem not the importance that makes this so. I also noted the paradox you spotted. It is a common problem in build forms solutions and with people accepting forms solutions.
I agree. verbose is not bad, as long as it's simple. I have seen fully automated form builders which are more difficult to use then just simple plain html/php, because you have to learn a completely new "FormBuilderLanguage".

Again, let's think of some use cases and think about the ideal interfaces, both from the programmers' perspective and the designers' perspective. Let's take an easy to use template for a front-end guy:

Code: Select all

 
<form action ="/login/" method="POST" >
    
    <label>Username</label>
    <input name="username" value="<?php echo $username['value']; ?>" />
    <span class="error"><?php echo $username['error']; ?></span>
    
    <label>Email</label>
    <input name="email" value="<?php echo $email['value']; ?>" />
    <span class="error"><?php echo $email['error']; ?></span>
    
    <input type="submit" value="submit" />
    
</form>
 
// or
 
<form action ="/login/" method="POST" >
    
    <label>Username</label>
    <input name="username" value="<?php echo $this->username['value']; ?>" />
    <span class="error"><?php echo $this->username['error']; ?></span>
    
    <label>Email</label>
    <input name="email" value="<?php echo $this->email['value']; ?>" />
    <span class="error"><?php echo $this->email['error']; ?></span>
<p class="note">Note: please fill in the same email adress as you used for your registratin bla bla bla</p>
    
// etc
    <input type="submit" value="submit" />
    
</form>
 
Something like that. So, this is just a use case for the situation in which the front end guy needs full control.
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Re: I figured out why I'll never be happy w/ php forms libraries

Post by jmut »

matthijs wrote:Following along as well. I just want to say that Arborint is right that you can only have a useful discussion if you take one use case and then compare different solutions.

And then second, you have to look into different use cases, from a simple login form to a complex, 50 fields form with a lot of logic.

The thing is, for a default simple login form, the more automated echo $this->form() works ok. But if you have a large registration or shopping cart form, it's a completely different situation. And my feeling is that most of you guys are mainly programmers (no offense if you're not!) so are looking at this from a programmer's viewpoint. So you want to be able to do echo $this->form and be done with it. But the (graphic) designer or front-end guy will have a very hard time with that and might not accept that. Because he wants to design field 8, 16 and 23 just a bit different. And he wants to be able to add a small extra note with field 26. And have a slightly different behavior in field 4. Etc etc. Or he wants to add another fieldset around a few form fields. Now, does he have to go back to the programmer and ask the programmer to add a few extra lines to the RegistrationFormcontroller class? No. he should be able to just edit his template file. And maybe you think these issues are not important, but I think they are. As Ninja said, forms are an important part of the site/app. They are tedious for the user as well! So every small detail that improves that user experience will make a big difference. And that's why it's difficult to have a solution in which you just dump out those 40 fields in some standard html.

Anyway, that's just to say that, I think, first, you have to support multiple situations (automated code generating versus customizable template like) and second, that you have to clearly define the use cases if you want to compare apples to apples.
Ok, yes, I had trouble reading it too...was in a hurry.
I think such cases where you have to handle really per field rendering stuff is quite rare. I mean in normal workflow you should have pattern after all, like all fields around some li tag or whatever, some label, a comment..then this and that...if has errors, append one div after each field or the like. I am not saying comment or whatever should be there for each field..but you should have some pattern.

- Still, even if per field specific rendering is needed , I don't see much trouble doing it in ZForm. For example you can use the viewScript decorator, it allowes you to define a view script to use for rendering per field.. So what you can do is set 'my_option' for each form element like 'element_1' etc etc. Then you can extend this viewScript decorator (so actually you'll use my_view_script decorator for each element, and not the default viewScript)...and this my_view_script instead of using the generic view script (which is like 80% of all you're fields), it will first check if file with 'my_option' exists ..(somewhere..a matter of convetion), and will use that file instead to render.
So at the end your designer can always create such file and know that this specific field will be rendered with this code/html. Of course you'll probably want to do this naming like form_element_1 or the like to be more flexible and have no collission with different forms containing same element names.

Also, it is really rare case , at least in my practice, that desginer will change something that will not require developer to hit in, either new functionality or the like....other stuff is just css + overwritte of images.

Other thing is, you can render the form in the tempalte element by element... this way you can add whatever additinal html around that you want.....this makes sense if no pattern you see in the html. After all I think we all agree that nowdays design is dones mainly with css and not some twisted tables that you donno what goes where.

It's doing the persistance for you (autoprefill), validation,filters, error messages and everything all at once.... you will have reaaally hard time following/maintaing this yourself...with html and tons of php doing some weird stuff around.

Bottom line, ofcourse there is nothing in the world that can make it all for you, I think such framework should do/solve your 80-90% scenarious that are most common - this will still saves you tons of time maintaining...even if the rest you have to do old style way.
And I certainly cannot imagine design without pattern whatsoever. With ZForm's decorators you can built anything you want.

You can enable,disable fields to be render for specific scenarios, enable/disable validation in certain cases etc etc.... I think it trully just gives you freedom.
Last edited by jmut on Thu Apr 24, 2008 8:13 am, edited 1 time in total.
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Re: I figured out why I'll never be happy w/ php forms libraries

Post by matthijs »

@jmut: sorry to say this and really no offense meant here, but: I read your post three times and I don't understand what you're saying. English might not be your primary language and neither is it mine so that could explain why I don't understand your post. But could you explain in some other easier way what you tried to say? I'd appreciate that, I am interested in what you have to say here.
webaddict
Forum Commoner
Posts: 60
Joined: Wed Mar 14, 2007 6:55 am
Location: The Netherlands

Re: I figured out why I'll never be happy w/ php forms libraries

Post by webaddict »

Interesting topic. I agree that writing forms is one of the most tedious jobs out there. Nevertheless, I also have to agree with Mathijs in saying that automating this process could be really hard, considering the fact that designers and users will not (always) be pleased with a form that is generated per request. So it has to customizable.

The two options I've seen in this topic are:
  • Generating the form on the fly from a certain object (less code for developer, hard to customize from template).
  • Hand-writing the form (more code for developer, easy to customize from template).
From where I'm standing there are two different kinds of logic involved in handling a form. The first would obviously be showing the (x)Html form (so presentation), the second would be the logic for filtering and validation. Mathijs is right in saying the presentation part of the form should be easy to customize, but then, we're programmers thus lazy thus we don't like to type the same thing over and over. But, thinking it over, one could conclude that the presentation (xhtml) of a form is rather static, while filtering, validation and showing the errors or prefilling the form's values is dynamic because the user's input is not static.

From my point of view, the best form library would be the one that can generate a template, but only does it one time and not for every request. It would create a template that contains placeholders for both error messages as for prefilled values. But then, you're still left doing all the filtering/validation/prefilling logic, so you actually just want .... scaffolding?
Post Reply