Comments for HTML Forms generation and validation
Re: Select Options
> Does anyone know if this has been
> implemented? I need
> optgroups for a project I'm working on,
> so I'd planned to
> write a quick hack to enable them --
> however, if this has
> already been implemented properly, I
> don't want to
> duplicate someone else's work.
Coincidently, I was planning to implement it in January as part of a major overhaul to the select input support. But feel free to develop whatever you need for now.
Re: Select Options
> Ok, I will try to implement it soon.
Does anyone know if this has been implemented? I need
optgroups for a project I'm working on, so I'd planned to
write a quick hack to enable them -- however, if this has
already been implemented properly, I don't want to
duplicate someone else's work.
Thanks!
Re: About other form generators
> Then why don't you just propose this
> class on PEAR?
>
> It's a shame that these projects keep
> existing without anyone knowing about
> them (PEAR is a very nice
> advertisementboard off course)!
>
> Please put this up as a proposal on the
> pear mailinglist (from which im not an
> active member) and see what the
> responses are, why not?!
>
> Imho too many usefull classes are not
> being included into PEAR just for
> reasons like "having my own little
> project". Don't know if thats the case
> here but it would be a shame if you'd
> miss out because someone was just
> earlier on PEAR (and QuickForm is
> already there and does a good job)
> because of it.
>
> Off course your project has to confirm
> to the Coding Guidelines.
>
Unfortunately that is not a viable idea. Basically the problem is that some PEAR people do not want what they call "competing packages", so some PEAR authors (the developers of competing packages) do all that can to keep out other packages, even if those are better than what they have.
The coding guidelines are often used as an excuse to keep other people packages. I use coding guidelines since many years ago, even before PEAR was ever dreamed. The problem is that I use my own coding guidelines, which are well defined and consistent, not the guidelines that a small group of people of PEAR have chosen to be the ones and the only to be accepted.
It is not realistic to expect anybody that uses the same coding guidelines for many years to change, just to be accepted in PEAR. It is like asking me to stop writing with right hand, that I use for many years, and start using the left hand instead, just because a small group of people decided that is the correct hand to use. It should not matter what was the hand you used to write good things, but PEAR people do not agree.
I am not the only one that does not agree with PEAR coding guidelines. Many, many authors dislike PEAR guidelines, some are proeminent authors. I recall that once Andrey Zmievsky (Smarty, PHP-GTK, etc..) said that "PEAR coding guidelines make him cry". As a result you do not see packages like Smarty as part of PEAR either.
Even if we agreed with PEAR guidelines, it would not be viable for many of us, that hardly have time to do what we do, to convert thousands of lines of our packages, just because they do not comply to PEAR guidelines.
But that is not the only problem about PEAR. For instance, once you submit your packages to PEAR, other people can mess your code with prior consent or agreement. That is disrespectful and hateful. Basically you loose control as if you no longer own the copyright of your code. Open source and loosing copyright is not the same thing. I do not object people using changed versions of my code, but I object people making changes that I did not agree to my projects in my main work repository. It is hard enough to keep up with the complexity of my projects, even more with a bunch of people messing with the code. Too many cooks spoil the broth.
Other than that, you do not have freedom to use whatever free software license you want to distribute your code. For instance GPL packages are banned in PEAR, and LGPL is discouraged. Personally I always use BSD license, so that would not be a problem for me, but it would be a problem for other authors that do not agree.
Originally, PEAR was expected to be CPAN for PHP, but AFAIK Perl CPAN does not impose such restrictions.
This forms class and all or my classes are distributed in the PHP Classes repository (www.phpclasses.org/). It is a package repository site that exists for more time than PEAR. It is certainly more popular according to Alexa site popularity rankings.
The PHP Classes site is much more focused in providing satisfaction to the authors that contribute to it. Therefore it has certain important features that PEAR does not have.
The PHP Classes site has now 250,000 subscribers, about half of those remain active in the site. This means that whenever you release a new class, about 120,000 users, eager to learn about new classes, are notified by e-mail about the new class. This is an extraordinary way for the class authors to get immediate exposure for their work.
The PHP Classes site keeps track of all the downloads of all classes. When a class is updated, the users that downloaded it are notified by e-mail about the new release, except for those that do not want e-mail notifications. This helps authors to keep their users upto date using the latest versions, so they do not have to waste time providing support to people using outdated versions, just because they were not aware of the updates.
The download records are accurate. This allows the authors to know how many unique users have downloaded a class. The site can also build top download and top rated charts (www.phpclasses.org/bro...) that are immune to fraud, so every author gets an equal chance for being recognized for the value of the classes that he is sharing.
There are other things that the PHP Classes site provides that PEAR doesn't. I do not have anything against those that contribute to PEAR, but unfortunately PEAR does not represent a consense among the PHP community, unlike for instance what CPAN represents for the Perl community.
Re: About other form generators
Then why don't you just propose this class on PEAR?
It's a shame that these projects keep existing without anyone knowing about them (PEAR is a very nice advertisementboard off course)!
Please put this up as a proposal on the pear mailinglist (from which im not an active member) and see what the responses are, why not?!
Imho too many usefull classes are not being included into PEAR just for reasons like "having my own little project". Don't know if thats the case here but it would be a shame if you'd miss out because someone was just earlier on PEAR (and QuickForm is already there and does a good job) because of it.
Off course your project has to confirm to the Coding Guidelines.
Re: form example with GetInputEventURL
> Manuel Lemos
> Can you post or send me one example in
> form.php with the new functions
> "GetInputEventURL" and
> "HandleEvent"?
> Thanks
That is meant mostly for custom input plug-in classes. Please take a look at the CAPTCHA plug-in class that comes with the class package.
form example with GetInputEventURL
Manuel Lemos
Can you post or send me one example in form.php with the new functions "GetInputEventURL" and "HandleEvent"?
Thanks
Re: Select Options
> That definately, would be the easiest
> option - the only problem I can see is
> catching any errors if a user tries to
> add groups that aren't chronological, or
> tries to nest option groups.
>
> But, it would fit in nicely with the
> syntax of Select Options in your class
> and I would happily use that approach.
Ok, I will try to implement it soon.
Re: Select Options
> I think this is a bit more complicated
> then I wanted.
>
> The way I see the OPTIONS do not have
> their definitions changed when they are
> grouped. So I think it would be better
> to let OPTIONS definition remain as it
> is.
>
> What can be added is the definition of
> the groups, associating a label to the
> values of the respective options, more
> or less like this:
>
> "OPTGROUPS"=>array(
> "group1"=>array(
> "value1",
> "value2"
> ),
> "group2"=>array(
> "value3",
> "value4"
> )
> );
>
> What do you think?
That definately, would be the easiest option - the only problem I can see is catching any errors if a user tries to add groups that aren't chronological, or tries to nest option groups.
But, it would fit in nicely with the syntax of Select Options in your class and I would happily use that approach.
Thanks
Ross
Re: Select Options
> One approach would be to create
> optiongroup array and use this to build
> the select options instead. So you
> wouldn't have an OPTIONS index for the
> AddInput function if the user chose to
> use optiongroups. (This should make it
> easier to include into the existing code
> and help clean up the logic of the
> optiongroups).
>
> Each item in the array would contain an
> array of select options and if it is an
> option group it will contain a label
> also. If an array doesn't have a label
> then it is not inside an option group
> and can be directly outputted as an
> option.
I think this is a bit more complicated then I wanted.
The way I see the OPTIONS do not have their definitions changed when they are grouped. So I think it would be better to let OPTIONS definition remain as it is.
What can be added is the definition of the groups, associating a label to the values of the respective options, more or less like this:
"OPTGROUPS"=>array(
"group1"=>array(
"value1",
"value2"
),
"group2"=>array(
"value3",
"value4"
)
);
What do you think?
A great developer-friendly class
Hi Manuel,
Simply a 'great' class - very thorough and exhaustive to the detail although one may not use each and every function from its API but who knows? When you need a feature and you know it is there, it feels good and that's what makes a software a success. Excellent and consistent coding style. A developer-friendly class in that it does client-side as well as server-side validations with a single configuration of the inputs whereas other classes such as SmartyValidate, FormCat, etc. do either client-side or server-side validations but not both. And to know it is over 5 years old means it is almost bullet-proof. Includes most features that developers look forward to using in their day-to-day coding which shows the author's experience-level.
Here are a few suggestions:
Although descriptive, the title of the class is long and too generic: Forms generation and validation. How about branding it with a short name? Such as 'PHORM' or 'DynaForm' or 'DynaGen' or 'DynaValid' or 'PFGV' or 'FGV' or something suitable (however, I'm not aware of existing trademarks). Branding makes a product more popular and a domestic name.
Considering its size, how does it perform? Is this class being used on any large/high-traffic/high-availability websites? If not, is it possible to dish out a 'Lite' version skimping out some fat? There are so many features in this class such as 'accessibility_tab_index', etc. that every site may not use. On the other hand, support for Smarty is refreshing and very much desirable to be retained.
Is there a way to implement features to configure changing the colors of the field-labels and flashing a dialog with a consolidated message for 'all' the errors (with an optional Beep) on the form? It may be possible with some plugin/custom functions but would be ideal to implement them within the class. Here is an example:
www.softcomplex.com/pr...
Date fields (dropdowns):
Prefer international format: [Year] [Month] [Day] (or is there a way to shuffle them depending on the locale?)
With the above arrangement, the class can effectively and dynamically filter the number of days in a month based on the Year and Month selection. For instance, Feb (28), Leap Year (29), Sep (30) and Dec (31). This helps in reducing lame data-entry errors as the code is self-correcting and self-validating.
Date Range: In case of two date fields for a range of dates such as Date of Arrival and Date of Departure (one >= the other), it would be thrilling to have the second date field automatically filtering out the invalid Years/Months/Days based on the Year/Month/Day selection in the first date. For instance:
A person arrives on 2000/3/15 and departs on 2000/3/25. When the user chooses the first date field as 2000/3/15, the Years in the second date field should show only years that are >= 2000. Once the user selects 2000 in the second date field, the Months dropdown should show only values >= 3; once the user selects 3 for the month in the second date field, the Days dropdown should show only days >= 15 as it doesn't make sense for someone to arrive after he/she departed (well, technically). Users would get a kick out of such interface for it being intuitive, intelligent and user-friendly which they experienced only in older client/server apps. This feature would be in addition to the equality (password) and difference (reminder) features. Is this something possible with Connect()/linked-select?
Reserved Words: Some vars (error, form, etc) seem to be conflicting with the reserved words of other interfaces such as Flash, Flex, etc. should the developer want to pass values to those interfaces instead of HTML.
ResubmitConfirmMessage: Incorporate a feature to disable the Submit button 'OnSubmit' as default.
Email Validation: Are the validations/regex in this class adequate? See:
www.ilovejackdaniels.c...
www.ilovejackdaniels.c...
Thanks much and keep up the good work...
---
PowerObject!