I understand the desire to capture forms as JSON, but one thing I've found
with my own very similar work on forms is that you really need the ability
to associate JavaScript code with various parts of the form definition.
Here's what I've done:
- you define your form hierarchically -- similarly to what you've described
-- as a JavaScript map rather than a JSON string
- you pass a reference to the map to the "form compiler", which parses the
definition and creates a series of functions ("thunks") that, when executed,
create the form -- usually as a background process driven by a recurring
event handler
- you get back a reference to a Form object, which you can render() by
attaching the prebuilt DOM nodes to a parent container
The nice thing about this approach vs. JSON representation is that I can set
any value in my form definition to either a simple scalar or a function to
be evaluated. So, e.g., I can say:
/* form */ {
widget: new qx.ui.container.Composite(),
layout: new qx.ui.layout.HBox(),
children: [
function (obj) {
items = [];
for (var i = 0; i < entries.length; i++)
items.push({
widget: new qx.ui.basic.Label(entries[i]);
});
return items;
}
]
}
which lets me include dynamically generated children in my form. Similarly,
I can add define a render function which will be run *when the form is
rendered". This means I can define the form generically and pre-build it,
then specialize it when I render it. An example might be a form that
includes elements which are made visible/hidden based on the properties of
the data in the form.
I can define event handlers in my form description as well, and data
bindings using Martin's binding stuff.
It will be difficult to support things like this in a JSON representation.
On the other hand, if you want to have a server send a form to the client,
including JavaScript code in the representation may be challenging, because
you'll have to eval(...) the code snippets. That's fine as long as you know
what context the browser runs eval(...) in -- in other words, what variable
bindings apply, etc. But perhaps you could avoid such problems by assuming
no particular execution context, but wrapping the code to be eval'ed in an
outer function that takes all the parameters you need to establish the
context for the code sinppets to run in.
Dave
I wanted to do a quick post here about the current JSON structure of
Blueprint and where I think it is going. I definitely would appreciate
comments on what people think I've done right or wrong with my design.
--
View this message in context:
http://www.nabble.com/Blueprint-JSON-Structure-Discussion-tp25722085p25802959.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
