Ideas for improvement

[mingfai]

Thanks Eric for creating the project. It's so great and I have been
using it for almost one week.

The 0.1 release is outdated and my comments/suggestions are based on
0.2beta. For my case, I am mainly use JSON to define a whole form with
all fields but not create every field in JavaScript, and I wish I
could define everything in a single JSON object.

1. Core additionals
* Add an ID field for Field
o With an ID, a field could be looked up and be
manipulated
o It is especially necessary as I define the whole
form with all fields in JSON.
* Provide a find() for Form/Group to find a child Field by
ID, and a findParent()/findContainer() to find the HTMLElement that
contain the Field. (it's just a wrapper of YUI Dom method)
* Make all configurable field as "member variable" so that
they could be generated by JSDoc. It may have been done in the 0.2beta
trunk already. for 0.1, we have to check what fields are configurable
in the code.

2. form layout
* currently, every field is generated as a row in a two
column table. For group, it's "indent" for one level.
* use case:
o some fields are related and we may want to put them
in one row. e.g. first name and last name, or four fields for credit
card number.
o a form may have section and at least we want to have
some spacing before/after a field row

* suggestion:
o the field definition support a few UI instruction:
"LineBreak", "SkipRow" etc.
o any UI instruction are in "serial manner"
o [idea] perhaps we could provide an option to tell
how many column the table should use. (each column refers to label and
field pair, not html table column)
o for complex layout requirement, i suppose we can use
parentEl to define an element and we position the element by
ourselves.

3. Field interaction
* it would be great if interaction among form fields could
be defined as rules in JSON. It is typical to have one form affect
another.
* use cases
o when a checkbox is checked, another field is enabled
(or unchecked/disable)
o when a checkbox is checked, a group is enabled and
expanded.
* Suggestion:
o no concrete idea yet. but probably we need to have
ID in every field in order to do UI interaction.
o the simpliest way will be allowing subscribe to
event in JSON. it may not be a good idea in design as to my
understanding, JSON is not suppose to contain executable code. Some
options are:
+ providing a function name as string
+ provide the UI handling code as string and be
eval()
o If UI interaction will be on the roadmap, we may
create a wiki page to identify the use cases.
o Field interaction could be very extreme as when one
field is changed, the whole form(i.e. all fields except the first
field) may be reconstructed. The Form Builder is actually an example,
but it is a class itself. It would be great if the form interaction
could be defined in the JSON form definition.

4. Improvement of Existing Fields
* ColorField:
o refer to my ColorField2. Cells of the original
ColorField is nice in design but a bit small to me.
o [idea] provide an boolean option to design if pop-up
or inline panel should be used. This parameter may be used by other
fields, too.
o I'm wondering if a ColorField should be extening
StringField or Select Field (or in a tree of Multiple Option Field)

* Group
o Allow a collapsible group be controlled by a check
box (rather than the "legend"). i.e. when a check box is checked, a
group is expanded.
o It could be done in different ways: pass in the
check box ID to the Group, define a check box in a group (as
"controller" or whatever), just make radio button and group separately
and use UI interaction to link them up.

5. Additional Fields
1. Radio Field.
* It might be good to create a MultiOptionField
abstract field, and have Select and Radio Button group extending it.
* I'm surprise this was not available in the first
release. I don't really need it myself but it's so easy to implement
so I've made one.

2. ImageMap Field: It is very desirable to have to allow user
to choose a value on an image map. So in the ImageMap Field, all image
map HTML attributes will be defined, i.e. shape, coords, and alt. And
a value will be associated to each option. The chosen value will
either set in a hidden field, or a select box, or a radio button
group.

3. Image Select Field: Similar to the Color Field, but show
different images for user to choose.

remarks:
- for those tagged as [idea], it's just idea and I do not need it
personally.
- there was other ideas for 0.1 but it seems it's handled in the
0.2beta trunk already, e.g. change to YUI style object (extension),
support AJAX request etc.

What do you think?

regards,
mingfai

[Deva Satyam]

>    2. form layout
>           * currently, every field is generated as a row in a two
> column table. For group, it's "indent" for one level.
>           * use case:
>                 o some fields are related and we may want to put them
> in one row. e.g. first name and last name, or four fields for credit
> card number.
>                 o a form may have section and at least we want to have
> some spacing before/after a field row
>
>           * suggestion:
>                 o the field definition support a few UI instruction:
> "LineBreak", "SkipRow" etc.
>                 o any UI instruction are in "serial manner"
>                 o [idea] perhaps we could provide an option to tell
> how many column the table should use. (each column refers to label and
> field pair, not html table column)
>                 o for complex layout requirement, i suppose we can use
> parentEl to define an element and we position the element by
> ourselves.

I disagree on this, the code itself should generate nothing that
forces a particular layout. What it should do instead is enclose each
element and group of elements in divs, each with a consistently build
className so that the visual designer by using these selectors, can do
whatever is needed.

For example, the field label should be in a label element, the input
element enclosed in a div with a className of inputex-input-field (or
something like that), then the whole set enclosed in a further div
with a classname of "inputex-field-set" plus a classname derived from
the name attribute (or the id attribute), groups should be enclosed in
a div (or in a fieldset tag) of classname of inputex-group and so
forth. The important thing is that each generic element type can be
identified plus exceptions can be made for a particular field group or
field set by using their name or id-derived classnames.

If a line break needs to happen after a certain field, you just set
the style for that div so that you get the botom padding, margin,
border or whatever you want in it. But don't mix code an style.

Satyam

[mingfai]

sounds good. I just checked that in 0.2beta, it's no longer using HTML
table to do form formatting, but use DIV with classname. A sample is
as follows:
<div id="container1" class="demoContainer">
<div class="inputEx-Group inputEx-valid">
<form method="post" action="" class="inputEx-Form"
autocomplete="off">
<fieldset>
<legend/>
<div style="clear: both;"></div>
<div class="inputEx-Group-GroupItem">
<div class="inputEx-Group-label">Firstname</div>
<div class="inputEx-Group-field">
<div class="inputEx-Field inputEx-
valid"><input type="text" size="20" name="firstname"/></div>
</div>
</div>
<div style="clear: both;"></div>
<div class="inputEx-Group-GroupItem">
<div class="inputEx-Group-label">Lastname</div>
<div class="inputEx-Group-field">
<div class="inputEx-Field inputEx-
valid"><input type="text" size="20" name="lastname"/></div>
</div>
</div>
<input type="submit" value="Change"/></form>
</div>
</div>

Looks like we need still need an ID attribute per Field in order to do
formatting easily. And if "<div style="clear: both;"></div>" do not
exist, how do we define the style of inputEx-Group-GroupItem to add a
line break? thx

regards,
mingfai

[mingfai]

>And if "<div style="clear: both;"></div>" do not
> exist, how do we define the style of inputEx-Group-GroupItem to add a
> line break? thx

I got it from Y! Answer. :-)
http://answers.yahoo.com/question/index;_ylt=AjzPp1xnfrZSCgSeEeUQhCojzKIX;_ylv=3?qid=20080423060734AATZkgW

Use display:block

[neyric]

Hi,
thanks for the suggestions, here are some answers (0.2beta) :

On 12 juin, 12:13, mingfai <mingfai...@gmail.com> wrote:
> 1. Core additionals
> * Add an ID field for Field
> o With an ID, a field could be looked up and be
> manipulated
> o It is especially necessary as I define the whole
> form with all fields in JSON.

This is necessary.
We also need it to use elements that already are in the DOM (more YUI-
like).
However, it has a drawback: we'll need to be very careful when
composing fields: in a list of url, url fields can't have the same id.

> * Provide a find() for Form/Group to find a child Field by
> ID, and a findParent()/findContainer() to find the HTMLElement that
> contain the Field. (it's just a wrapper of YUI Dom method)

same as above
For the time being, you may want to use Group.getFieldByName

> * Make all configurable field as "member variable" so that
> they could be generated by JSDoc. It may have been done in the 0.2beta
> trunk already. for 0.1, we have to check what fields are configurable
> in the code.

I still have some issues with my doc generator, I'm working on this...

> 2. form layout
> * currently, every field is generated as a row in a two
> column table. For group, it's "indent" for one level.
> * use case:
> o some fields are related and we may want to put them
> in one row. e.g. first name and last name, or four fields for credit
> card number.
> o a form may have section and at least we want to have
> some spacing before/after a field row
>
> * suggestion:
> o the field definition support a few UI instruction:
> "LineBreak", "SkipRow" etc.
> o any UI instruction are in "serial manner"
> o [idea] perhaps we could provide an option to tell
> how many column the table should use. (each column refers to label and
> field pair, not html table column)
> o for complex layout requirement, i suppose we can use
> parentEl to define an element and we position the element by
> ourselves.

cf Satyam's comment.
I already switched from tables to divs and inserted CSS customizables
linebreakers.
I'm still working on the CSS classnames which currently are in a mess.


> 3. Field interaction
> ...

Yes !
This require some thinking... Let's create a page on the wiki with
some use cases...

> 4. Improvement of Existing Fields

> 5. Additional Fields

I'm creating pages on the wiki for these too :)
All ideas for new fields or enhancement are welcome !

Eric