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 :)
On Fri, Oct 2, 2009 at 6:56 PM, MootCycle <[email protected]> wrote:
>
> 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 hierarchy they would in the source code and are built recursively
> (thus
> the deepest nodes are built first.) Wherever possible, I use data objects
> supported by JSON in the same format that qooxdoo would expect to make the
> translation as easy as possible. For example, all blueprint objects support
> a qxSettings node which is always passed directly into a this.set()
> function
> during construction. Anyway, here's a basic Blueprint object/container:
>
> {
> "objectClass": "blueprint.ui.window.Window",
> "objectId": "myTopContainer",
> "type": "top_container",
> "qxSettings": {
> },
> "constructorSettings": {
> },
> "blueprintScripts": {
> },
> "blueprintFunctions": {
> },
> "prerequisites": [
> ],
> "contents": [
> ],
> "components": {
> }
> }
>
> objectClass (required) - This is the class that the object should be built
> from. I've looked a little at some of the other serialization projects and
> perhaps this node would be better named as clazz.
>
> objectId (optional) - Each blueprint top_container is a namespace for the
> purposes of variable replacement. The object Id serves as a way for objects
> to reference each other. If it is left undefined, the object is anonymous.
>
> type (required) - This defines the object as one of three things:
> * object - An object to be built, also a base case for the manager
> recursion.
> * container - An object that contains other objects; a recursive
> case.
> * top_container - This is a container that is also a namespace.
>
> qxSettings (optional) - This node will be passed directly into a this.set()
> function in a blueprint object. All key/value pairs are assumed to exist on
> the qx object.
>
> constructorSettings (optional) - I created this node to handle cases where
> an object has required constructor arguments. In practice, I haven't used
> it
> very often, and I'm not sure that it has to remain in the format.
> Currently,
> if constructorSettings is used, the blueprint object has to explicitly
> define what the arguments do. I would like to make some changes here, but
> I'll save the discussion till later.
>
> blueprintScripts (optional) - This node contains javascript code that is
> run
> immediately after the form is created. This node is currently only executed
> on the top_container. I made this decision because objects are created
> recursively, and only when the top container is fully created can I be sure
> that all the other objects in the namespace have been created. I could see
> having the blueprint.Manager collect all the blueprintScripts it encounters
> at any node until after the namespace is constructed and executing them
> then, but I don't see that the added complexity gives any additional
> functionality. If someone had a good argument otherwise, I'd certainly
> listen to it.
>
> blueprintFunctions (optional) - This node contains functions which are
> attached to the top_container object. I prepend the functions with
> 'blueprintFunction_' before attaching them to try to avoid conflicts with
> existing qooxdoo functions. I feel like this a bit of a hack. I think I
> should probably create an array property on the top container and then
> store
> the function references there rather than eval them directly onto the
> object
> as properties. Again, any input on this subject would be appreciated.
>
> * Quick note: Currently neither the blueprintScripts or blueprintFunctions
> code is being minified. I do think this is a potential improvement in the
> future.
>
> prerequisites (optional) - I created this node with the idea that some
> blueprint elements might be required for namespace operation without
> belonging in the standard layout hierarchy. All prerequisites must have
> object ids associated with themselves otherwise they cannot be referenced.
> (Generating a prerequisite without an object id produces a warning.) The
> only case where I have used this node is with a
> blueprint.ui.form.RadioGroup, which cannot be added to a container but is
> required for radio buttons to operate. There are some obvious weaknesses to
> this approach, but I haven't thought of a better way to do it (yet.)
>
> contents (required for containers) - This node contains the objects to be
> built recursively inside the top_container. The contents node is an array
> which must contain a sequence of objects that have the format: [{
> "layoutmap": {}, "object": {} }, ...]. I expect this format even in the
> case
> of a VBox or HBox layout where a layoutmap would be null. I'm just trying
> to
> standardize the structure of the contents node to keep the blueprint
> codebase simple.
>
> components (required for certain objects) - The idea for this node is that
> it contains objects to be used in conjunction with the parent object. A
> good
> example of this node would be with a blueprint.ui.table.Table. The table
> object requires a table model, which would be contained in the components
> node. As with the constructorSettings node, the details of how components
> are used must currently be specified in the constructor of the blueprint
> object. (Note: there are no components supported for a
> blueprint.ui.window.Window; I'm just explaining the node here.)
>
> -----
>
> I'm open to discussion about any of these elements, but the main
> things
> that are on my mind right now are the constructorSettings and components
> nodes. I think that there may be a clever way of implementing the
> components
> node to work in a similar way to a **kwargs argument in a python program.
> For example, qx.ui.table.Table expects a tableModel in the constructor, but
> I should be able to loop through the components array and use the
> "tablemodel" key to generate the correct object and then use this.set() to
> apply the model with some very generic code. I haven't had a chance to look
> at too many cases, but this particular one should certainly work. I'm
> trying
> to think of various ways to allow the blueprint format to provide more data
> types than standard JSON can to the qooxdoo elements. As I see it right
> now,
> I already have integers, strings, booleans, arrays, and
> object/dictionaries.
> The primary missing piece would be full qooxdoo objects. I'm going to play
> around with this idea over the weekend here, but I'm hoping to get a bit of
> feedback to this thread. Please let me know what you think.
>
>
> Thanks,
> -Dan
>
> --
> View this message in context:
> http://www.nabble.com/Blueprint-JSON-Structure-Discussion-tp25722085p25722085.html
> Sent from the qooxdoo-devel mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
