IDE Issue 2

From MemberWiki

Jump to: navigation, search

IDE Issue 2: Reconciling "data", "arguments", "parameters", and "topics"

Original write-up

This issue is about data and parameters that apply to a given widget instance.

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 dialog
  • The widget's automatically assigned ID
  • The widget's class name (?) (or would this be class names?)
  • topics published
  • topic consumed

Notes and questions:

  • "value", "arguments" and "properties" all have a name, a type, and a default value
  • We might need to take inheritance into account. For example, some widgets might inherit from a base class a property that defines an onChange callback.
  • 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.

Jon's proposal (Updated 12/29/07)

  • I am sold on treating a widget's "value" as something different and special than its arguments and properties. Therefore, I recommend a <value> element that corresponds to the 'value' property within jMaki's widget.json format
  • For "arguments" and "properties", I still like the idea of consolidating the two into a single mechanism. Because Aptana has such a rich definition for properties described at the following URLs(along with complete API definitions for various leading Ajax toolkits), I recommend using Aptana's <property> element as the starting point for such a consolidated mechanism. In particular, I recommend that the widget metadata leverage the properties element proposed for the API metadata:
  • (Revised proposal as of 12/29/07) Regarding what to do about IDs, originally I had recommended that we avoid the issue, but I am now convinced that we should not (and perhaps cannot). My latest thinking is that we need to support two workflows involving IDs:
    • For workflows where IDs are to be entered manually, we make sure that the metadata is set up such that the widget ID can be listed among the widget properties (and therefore is a candidate for appearing in a widget property inspector dialog). For example, the property name might be "id" and the property datatype might be "ID".
    • For workflows where IDs are generated automatically by a tool or other pre-processing software agent, we architect things such that an "id" field is passed to the widget constructor (inspired by Adobe's proposal)
  • (Revised proposal as of 12/29/07) Regarding what to do about 'class' (as in CSS class selectors), originally I had recommended that we avoid the issue and still think that is the case. I can see two ways we might consider doing something about 'class'. First, some widgets will be stylable and might advertise what classes can be used to customize the appearance of the widget, but that seems like something we can leave to the widget's free-form documentation. Second, some widget systems might find a way to allow users to define their own classes and might want to allow entry of those custom classes on a property inspector dialog, but this can be done using simple string datatypes and a little bit of supporting logic within the Ajax toolkit (or an adapter layer of logic that sits between the OpenAjax world and the underlying toolkit world).
  • The pub/sub metadata (i.e., topics published and consumed) should be separate from the arguments and properties

JON: Maybe we need to add something for a particular type of widget property that holds a list of CSS classnames which a tool should append to the 'class' attribute for the widget instance. At the moment, I don't think we need this, but this note is a reminder about this question.

Retrieved from "http://www.openajax.org/member/wiki/IDE_Issue_2"
Personal tools