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 t
I did look at your prototype, and it is pretty clear to me that we're working
along similar lines. I am hoping to contribute to the discussion both
directly and through development of Blueprint. Since we're already using
Blueprint in an internal product, I do have an interest in developing
bluepri
Yeah, type can probably be gotten rid of. The recursion can happen or not
depending on the existance of the contents/children node. That wouldn't be a
difficult change to make. Also, I do prefer children to contents.
I'm not sure how I feel about an events key. The blueprint scripts node
already
Hi Dan,
thanks for your comprehensive input and asking for suggestions. I'd like
to remind you to take a closer look at the existing bug report and demo
(if you haven't yet), that show some premature ideas of a declarative
qooxdoo UI:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=2685
http://demo.q
Here I some of my thoughts:
I dont think "type" should exist. You can add a key "events" : { "appear" :
fucntion(e) {} } to handle those case that the top container should do
something.
Actually, "events" should be a key for every object.
Every key that is not "reserved" to this dialect should be
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. The
basic design philosophy for the JSON is that the layout objects exist in the
same h
