big picture...

[GoogleCodeExporter]

Hi, not an 'issue', just wondering where you are going with this project?

I've played with it a bit, and here's my $.02

You have built a lovely simple way to define a fairly complex form.  But in
some ways, it's TOO simple.

i'm working on a little project where there are a dozen or so complex
forms, perhaps hundreds of fields that will need to be defined.

the first thing i did was write a wrapper to replace your hand-crafted demo
forms with a data-driven model.  i create my forms dynamically from the
data schema.  when i add a data element, it includes fields that define
initial values, how it behaves on a form, and what it looks like in the
database.  (sounds complicated, but it's just a spreadsheet that I load as
a CSV).

but it's going to be more complicated than that.

so here's what i've been running into:

addElement has the five basic elements (prompt, id, type, value,
additionalParams), but immediately I find myself wanting to add more.  

for example, I would like to add a validation callback in PHP (perhaps
using create_function()).  you offer a 'required' parameter, but real life
is more complicated.

in some cases the options for a field are pulled dynamically out of the
data (eg: your editor may have a view that shows your function names).
so i would like to be able to provide a PHP function that creates the array
of options for a pull-down (or autosuggest).

it's not clear how i can specify whether to send parameters to jquery or to
HTML (or whatever).

you rely on CSS to lay out the form, but you don't allow the programmer to
suggest a structure. 

when I think of a form, it's a complex structure.  it may have multiple
tabs, multiple panels that group similar items,  pop-up sub-forms, etc.  
look at the 'preferences' tab on your browser or text editor for an example. 

consider letting the programmer add structure  'levels' to the form.  this
is like a menu with <ul> and <li>. - CSS determines whether it is
horizontal, vertical, whatever, and what each element looks like.  

with a suggested structure, CSS has something to work with - maybe
rendering the top level as tabs, or as separate pages for a mobile device.
 it also providing theme consistancy at the bottom level.  maybe make the
top level explicit in your definition language (addElement 'startPage'),
because CSS can't really handle some of the things that we might want to do
with forms.

(i'm already sending in 'style' as an additionalParam, that's great).

XHTML compliance is a nice idea.  but don't lose sight of the goal.   when
someone is using your form builder, they have have more to do than
'username/password'.  i would focus efforts on making this class the
obvious choice for someone writing projects with complex web forms.

you are going to be swamped with 'enhancement' requests.   why not make the
class extensible, letting programmers write (and contribute) widgets.

for example, i was working today on a jquery 'radio-button' with three
color-coded slices (NOW, LATER, DONE).   if i use it, then i'm going to
need to add it to the form class.

this widget taught me something else too - i learned that the programmer
really needs to drill into the implementation details.  for example, if I
want a 'submit' behavior with a datepicker, i need to use the jquery method
onSelect.  but a jquery button does not have any methods, i need to use the
html method.

maybe that's something your class can hide for the commonly-used methods,
provide common behaviors without having to study the details of jquery and
class.form.php.

i'm excited by your project, i think there is a need for it.  there's so
much to do.

Original issue reported on code.google.com by tom.bere...@gmail.com on 12 May 2010 at 8:45

[GoogleCodeExporter]

Tom,

Thanks for taking the time to provide this feedback.  I enjoy learning about how
users are using the project in their development.  I will respond to this with 
my
thoughts shortly.

- Andrew

Original comment by ajporterfield@gmail.com on 13 May 2010 at 1:57

[GoogleCodeExporter]

There's quite a few individual items in your initial message.  I will try and 
address several.  Let's start with...

"you are going to be swamped with 'enhancement' requests.   why not make the
class extensible, letting programmers write (and contribute) widgets."

Growing/strengthening this project's development community is very important to 
me.  Currently, there are two members with commit 
access through subversion and the code.google.com interface - moncojhr and 
myself.  In order to be given commit access, a member 
must prove him/herself to a competent programmer that works well in a group 
environment.  This includes being polite and respectful 
within the community.  The easiest way to get your foot in the door is to 
provide a patch for the project.  We will review it and provide 
feedback if applicable.  If it's approved and we thinks it's a good fit, we 
will include it in the live version.  Another approach is to 
participate in code review.  There is a google group - 
http://groups.google.com/group/php-form-builder-class-developer - created 
specifically for reviewing subversion commits.

- Andrew

Original comment by ajporterfield@gmail.com on 13 May 2010 at 9:04

[GoogleCodeExporter]

i'm in total agreement with your 'how to be a contributor' roadmap.   but i'm
suggesting something considerably less difficult.

there are hundreds of JQUERY add-on widgets.   their authors have simply built a
plug-in that conforms to the standard JQUERY architecture.   over time, the 
cleanest
ones have been adopted into the core by the JQUERY team.

a trivial example for a FORM BUILDER widget would be a canadian provinces 
version of
'states' (i live in toronto).  someone surely will need the 28 provinces of 
bulgaria
too.  

this shouldn't require forking your class (or reimplementing with each 
release).  a
programmer should NOT have to modify CLASS.FORM.PHP.   it should be as easy as
subclassing (or copy-and-pasting) 'states' in his program, and changing the 
initial
values.

Original comment by tom.bere...@gmail.com on 14 May 2010 at 12:44

[GoogleCodeExporter]

My response to...

"when I think of a form, it's a complex structure.  it may have multiple
tabs, multiple panels that group similar items,  pop-up sub-forms, etc.  
look at the 'preferences' tab on your browser or text editor for an example."

A recurring theme in your initial post is that the project is too simplistic to 
use
in a complex scenario.  To some extent, I agree with you; however, the project 
is
flexible enough - elementsToString() function, css-driven structure, etc - to be
integrated into custom environments.  The examples provided offer a basic demo 
of
what I consider the core/key functionality.  They aren't meant to showcase the 
full
potential of how this project can be used.  There's a fine line between what
functionality to include in this project, and what functionality to leave in the
hands of the user/developer.  Typically, I will listen to the feedback coming 
back
from people using the project to gauge whether or not it makes sense to include 
some
new feature.  XHTML strict compliance was consistently coming up in the issue 
tracker
and google group, so we decided to address it and build it into the project.

I final thought...

I have no data to back this up, but I don't think the majority of forms on the 
web
contain multiple tabs, panels, and pop-up subforms (whatever those are).  This
project will never to able to fully support everything that a developer wants to
accomplish with a form - it's unrealistic to attempt this.  If this project can
satisfy the needs to 80% of the developers that are using it, I feel that we've
provided a successful, useful piece of software.

Original comment by ajporterfield@gmail.com on 16 May 2010 at 3:11

[GoogleCodeExporter]

Original comment by ajporterfield@gmail.com on 17 May 2010 at 11:15

• Changed state: Invalid