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
