Markup/Template vs HTML to define layout - 2 different usage scenarios

[mingfai]

>InputEx uses no html (it is the opposite of unobtrusive librairies): all the fields and forms are configured using json, then rendered by manipulating the DOM.

i wonder if it's too ambitious to attempt to define any kind of markup/
template to construct the layout in a flexible way. there could be two
different scenarios

- for simple case, the whole form could be rendered by inputEx. In
long term, a JavaScript template solution could be used. As a form and
fields are defined, it's possible to make a Dialog ( a series of form/
page). Like this:
http://www.bubbling-library.com/eng/api/docs/plugins/wizard-examples.html

- for cases that require advanced layout, users define their own
layout, and assign ID for every field (and the form). A form is
defined in JSON by inputEx, the definition could do progressive
enhancement of the fields, setting default value(optional), add
validation, and some kind of interaction. In this usage scenario,
inputEx only transform some HTML elements (just like YUI Editor turn a
textarea to an editor) and add behavior to them, without altering the
layout.

for the 2nd case, i actually expect the form definition, validation
rules be defined on the server-side. (for Java, it's pretty easy to
transform objects to Json)

i have a form on hand to add validation and some server interaction
functionality. The form is made from Accordion example:
http://www.i-marco.nl/weblog/yui-accordion/form/ . Ideally, inputEx
should utilize the accordion widget to create the form but in short
term, it would be more realistic to directly use HTML to create the
form and use inputEx to manage the other aspects like validation.
That's why I come up with the two usage scenarios

regards,
mingfai

[neyric]

Progressive enhancement would definitely make inputEx more YUI-like
and more flexible.
However, it requires many changes on the actual code base.
I think it is better to wait for YUI 3 and make the inputEx.Field
class inherit the Element Utility.

>  - for simple case, the whole form could be rendered by inputEx. In
> long term, a JavaScript template solution could be used. As a form and
> fields are defined, it's possible to make a Dialog ( a series of form/

> page). Like this:http://www.bubbling-library.com/eng/api/docs/plugins/wizard-examples....

The wizard pattern is indeed interesting. It should be possible to
implement it as a subclass
of inputEx.Group.

> for the 2nd case, i actually expect the form definition, validation
> rules be defined on the server-side. (for Java, it's pretty easy to
> transform objects to Json)

You should ALWAYS perform validation server-side. You cannot trust the
browser.
Json libraries now exist for every languages .
inputEx validation is more a matter of user interaction.

However, it is troublesome to code validation twice...
We could add features to perform server-side validation in
inputEx.Form

[Mingfai]

> for the 2nd case, i actually expect the form definition, validation
> rules be defined on the server-side. (for Java, it's pretty easy to
> transform objects to Json)

You should ALWAYS perform validation server-side. You cannot trust the
browser.
Json libraries now exist for every languages .
inputEx validation is more a matter of user interaction.

However, it is troublesome to code validation twice...
We could add features to perform server-side validation in
inputEx.Form

agree to some extent. server-side validation is a must, but it's also good validation at the client side to give an immediate feedback to the user. e.g. to validate the format of email address.

it would be nice if in the inputEx form/field definition, a validator is separated out. Then both the client and server could read the same json definition for the validator. On the client side, inputEx takes care of the JS validation, and on the server, it intepret the validator in the server's way. it's just an idea, probably at the end it's easier to define two different fields for client and server validator.

inputEx could probably do Ajax validation. It makes use of the YUI2 connect or YUI3 io to talk to the server.

Let's put the validation plan in wiki.

regards,
mingfai

[Mingfai]

see: http://code.google.com/p/inputex/wiki/Validation