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 covers adding events to objects if necessary. I don't know if adding
another node adds any functionality. Also, right now with a single scripts
node, the 'behavior' is separate from the design. This is useful for the
projects I'm using blueprint with since it is easy to drop in canned events
and scripts into that one node. The main advantage I see to an events node
would be that it might be more readable to someone looking directly at the
json. Eventually, I want the designer to be able to handle full form design,
so I don't think this would be an issue.
I think I also like clazz better. It's more qooxdoo-ish and brings blueprint
a step closer to the UIDeclaration prototype. As for qxSettings, I still
prefer having a node that I can pass directly into a this.set() command
without needing to modify or delete other 'reserved' keys. Using qxSettings
makes the blueprint manager and mixin code simpler for me to maintain right
now. I do like the idea of making the json structure simpler overall, but I
want the objects to be easily built and serialized. Having an area of
'automatic' settings makes this easier for me.
Thanks for the comments,
-Dan
Guilherme Aiolfi wrote:
>
> 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 treated like a
> property to the instantiated object of "clazz" (i like clazz instead of
> objectClass).
>
> clazz: "qx.Sth.Obj",
> liveUpdate: true // liveUpdate is not "reserved" then it should be used
> like
> a property.
>
> Then there is no need to qxSettings.
>
> Every "property" should be able to instantiate an object:
>
> "layout": //property
> {
> clazz: "qx.ui.layout.HBox",
> padding: [2, 3] // here again, another property
> }
>
> and
>
> "children" or "contents": /// i like "items" to be shorter, but "children"
> is more qooxdoo-like
> [
> {
> clazz: "qx.ui.form.TextField" ,
> options: { row: 1 } //options to be used with container.add()
> }
> ]
>
> But I have to be honest and say that I haven't thought too much about :)
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
--
View this message in context:
http://www.nabble.com/Blueprint-JSON-Structure-Discussion-tp25722085p25798641.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
