[OpenAjaxIDE] IDE Issue 2: Data, arguments/parameters, and topics
jferrai at us.ibm.com
Wed Dec 5 14:54:53 PST 2007
IDE Issue 2: Data, arguments/parameters, and topics
This issue is about data and parameters that apply to a given widget
There is confusion regarding the original strawman XML proposal for widgets
where there is a <property> element but lack of clarity about how this
relates to the widget constructor function and the things that might appear
in property inspector dialogs.
There is a related issue regarding widget "values". In jMaki, there is a
distinction between "value" and "args". In jMaki, "value" corresponds in
concept generally to the HTML notion of a value for a form widget and can
be bound to a dynamic data feed. "args" is a JSON object.
In Adobe's proposal, constructors have 3 arguments: (1) the element's ID,
(2) a "selector" (is this really a class name?), and (3) an object that
contains a set of "options". It looks like jMaki's "args" is similar in
concept to Adobe's "options".
The IBM proposal in the Gadgets TF talks about expressing pub/sub topics
via properties. jMaki has a separate data structure for pub/sub topics.
Here is an attempt to capture all of the sorts of things that might be
classified as "data", "arguments", "properties" and "topics". Note that
there is some overlap and redundancy:
The "value" of the widget (in the HTML sense and jMaki sense)
The arguments to the widget constructor
The properties that might appear in the widget's property inspector
The widget's automatically assigned ID
The widget's class name (?) (or would this be class names?)
Notes and questions:
"value", "arguments" and "properties" all have a name, a type, and a
We might need to take inheritance into account. For example, some
widgets might inherit from a base class a property that defines an
Is there a unified approach to managing IDs and styling across the
Ajax industry? For example, do Dreamweaver, jMaki, Dojo, and Ext.js
use the same approach? Seems unlikely.
I am sold on treating a widget's "value" as something different and
special than its arguments and properties
For "arguments" and "properties", I still like the <property> element
there is a single list of properties
there is a hint for each property that tells the IDE
whether that property should appear in an inspector
at runtime, any properties that are different than their
default value are passed to the widget constructor
Don't address IDs and styling in the first version of our
specification. The IDEs and toolkits need to address those topics on
The pub/sub metadata (i.e., topics published and consumed) should be
separate from the arguments and properties
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE