[OpenAjaxIDE] an odd object case

Jon Ferraiolo jferrai at us.ibm.com
Mon Jul 20 17:41:01 PDT 2009

See responses below.

ide-bounces at openajax.org wrote on 07/20/2009 02:26:31 PM:

> [OpenAjaxIDE] an odd object case
> Lori Hylan-Cho to: ide
> 07/20/2009 02:30 PM
> Hi All
> Kin came across a case last week of a widget constructor that takes
> three arguments: a string, an object or array, and a config object.
> We spoke at length over IM about the second argument and how to
> specify it in the metadata in a way that would be useful to an IDE
> in generating a user interface for that argument. The datatype is
> fairly straightforward; it's
> datatype="[String]|Object"
> The spec says that <property> tags are only allowed as children of
> <parameter> or other <property> tags if the datatype is Object. I
> assumed that since the argument can be an Object, we could use
> <property> tags to describe the object's properties without
> violating the spec's rules, and that IDEs would need to be smart
> enough to know that this information was for the Object case only.

Yes. I have now tweaked the wording in the spec to accommodate this
scenario. Here is the new description:

If a <property>, <parameter> or <returnType> element has a datatype
attribute whose value is "Object" (e.g., datatype="Object") or whose value
is a list of datatypes that includes "Object" (e.g., datatype="String|
Object"), then that element MAY contain <property> or <properties>
sub-elements. In this case, the <property> elements provide descriptive
detail about the various properties on the Object.

If a <property>, <parameter> or <returnType> element has a datatype
attribute whose value is "Function" (e.g., datatype="Function") or whose
value is a list of datatypes that includes "Function" (e.g.,
datatype="String|Function"), then that element MAY contain <property>,
<parameters>, <returnType>, <returnTypes> sub-elements. In this case, the
<parameter> and <returnType> elements provide descriptive detail about the
parameters and return types for the Function.

If anyone sees a problem with the above wording, please speak up.

> From there it gets a bit trickier. The problem is that the Object in
> question does not have named properties. It has one or more
> properties (which are themselves Objects) that are identified by
> Strings of format url (relative or absolute file path). The Object
> that the String identifies *does* have named properties that must be
> specified in the metadata in order for the IDE to know what kind of
> UI to present.
> For example, the Object version of the argument in question could be
> specified as follows:
> {'1.jpg': {caption: 'Keylin', href: 'keylin.html'}, '2.jpg':
> {caption: 'Gustavo', href: 'gustavo.html'}, '3.jpg': {caption:
> 'Amalia', href: 'amalia.html'}};
> Kin's and my question is: How do we specify such a hash-like thing
> in the metadata so that it's clear to the IDE what the important
> pieces of information are? As people, we can read the example code
> and see that the labels are Strings representing the image path and
> that the corresponding Objects have two properties: caption and href
> (it turns out that there's also a third, thumbnail). But how do we
> specify the Object's properties in the metadata while also
> describing the datatype and format of the Object's label in lieu of
> a fixed property name?

My best suggestion is to leverage the 'format' attribute. The 'datatype'
attribute is meant to describe the raw JavaScript datatype, which in this
case would be Object. The 'format' attribute provides supplemental semantic
metadata. But now comes the question about whether this particular case is
a common industry case or whether this is a one-off scenario. Three

(1) If this is a standard case across the industry (e.g., JSON hash table?
ImageList?) and can be described completely so that we make the industry
more interoperable, then we might consider sneaking in a new built-in value
for the 'format' attribute (along side of format="id", "class", "email",
etc.). Perhaps format="JSONHash".

(2) On the other extreme, if this sort of JSON structure represents a
one-off scenario for a single toolkit (e.g., FooToolkit), then we should
consider leveraging the extensibility feature in the 'format' attribute
where the value is a URL. Perhaps

(3) In the middle, if we decide it isn't appropriate to define a new
built-in value for 'format', but this is a common feature across multiple
toolkits, then we could leverage the extensibility feature in the 'format'
attribute using a URL value, but define a OpenAjax.org URL for this, such
as format="http://openajax.org/metadata/formats/JSONHash". This approach
would provide a "standard extension".


> Thoughts appreciated.
> cheers,
> Lori
> _______________________________________________
> IDE mailing list
> IDE at openajax.org
> http://openajax.org/mailman/listinfo/ide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20090720/a3c88619/attachment.html 

More information about the IDE mailing list