[OpenAjaxIDE] Example of how Adobe is using the Widget Meta Data ...

Lori Hylan-Cho lorihc at aptana.com
Thu Aug 21 13:00:14 PDT 2008

Hi Jon

Either I'm not understanding you, or you're not understanding me. :-) All of the markup in my example would have been in the metadata file anyway; the only thing I added was <footag> (i.e., a single tag) to group some properties together.

I *know* I'm not understanding your suggestion about the property bag and the widget's JavaScript. The Dreamweaver scenario is that the Dw user is given an opportunity to set properties for the widget *at insertion, aka authoring, time* (and, ideally, after insertion via a property inspector, but that's a bit hampered by the re-editing issue Kin brought up). The widget's runtime JavaScript never comes into play.

Dreamweaver is just dropping the contents of the <content>, <javascript> and <require> tags into the user's page after first making the @@ and %% subtitutions. If the contents of a <javascript> tag contain a constructor that happens to take an options object as an argument, how is the IDE to know which widget properties belong in that options object?

Are you suggesting that instead of actually passing that options object as a constructor argument, we should be adding propertyvalue = this.setPropertyValue(propertyname, value) calls to the <javascript> that's specified in the metadata? How would the IDE know to do this? Would it be expected that all properties be set this way, whether they're specified in the constructor or not?


Jon wrote:

<footag> and property bundles
Regarding Lori's <footag> idea, that's an awful lot of markup. There has to be something simpler. Right now, a widget's JavaScript can get the values of an individual property via:

propertyvalue = this.getPropertyValue(propertyname);

Lori, why the need to bundle properties into a collection? Is it too slow or too cumbersome to grab each of the <n> properties when you need them? In the reference implementation, we discovered that it made sense to create under the hood within the widget wrapper an object that holds all of the property values. Under the hood, the code looks something like this, which turns out is about as fast as things would be if a property bag were assembled and passed as an argument:

// How getPropertyValue is implemented within the reference implementation
this.getPropertyValue = function(propertyname) {
return this._properties[propertyname];

However, if people feel it is needed, we could add a new API (e.g., this.getAllProperties) that returns an object that holds the complete property bag.


[cid:1__=07BBFE3FDFC6553B8f9e8a93df938 at us.ibm.com]"Kin Blas" <jblas at adobe.com>

"Kin Blas" <jblas at adobe.com>
Sent by: ide-bounces at openajax.org

08/21/2008 12:38 AM


<ide at openajax.org>



Re: [OpenAjaxIDE] Example of how Adobe is using the Widget Meta Data ...

Whoops, my bad. Yes Lori, my fx examples were missing a closing brace. That is, the fx option is supposed to pass an object inside the options object:

jQuery("#jQueryUITabs1 > ul").tabs({ event: "click", fx: { height: “toggle”, opacity: “toggle” }});

--== Kin ==--
From: Lori Hylan-Cho [mailto:lorihc at aptana.com]
Sent: Wednesday, August 20, 2008 7:05 PM
To: Kin Blas; ide at openajax.org
Subject: RE: [OpenAjaxIDE] Example of how Adobe is using the Widget Meta Data ...

This is where my original proposal, which was rejected in favor of a property bag (which, to be honest, I never fully understood), comes in. I was thinking in terms of constructor arguments, and I think that concept morphed into the more generic widget properties -- which may or may not be arguments to the constructor. (I of course thought of constructor arguments because that's how Spry widgets work, and that was the world I was coming from. See http://openajax.org/pipermail/ide/2007q4/000170.html :-) So the idea was that if one of the constructor arguments was an object which bundled a bunch of widget properties, you could express this in the metadata with

<argument name="id" type="string" format="id" default="uiTabs" />
<argument name="options" type="object" format="options" />

<option name="opacity" type="string" default="none" />
<option name="height" type="string" default="fixed" />

With the idea being that the name "options" corresponded to the tag <options>. I think this was rightly rejected, because we need <options> for other things, and as I mentioned, not all widgets take their properties as constructor arguments (in Kin's jQueryUI Tabs example, id is not an argument, for example... and I'm not even sure it could be called a property in this case, but that's another story).

However, we still don't have a good way to bundle up properties that are expected to be passed to a widget as an object rather than being set individually -- and it doesn't seem like it should be up to us to determine how the widget wants its properties set. It should be up to the widget developer. If she writes a widget that takes an options object as an argument, we need a way to describe this in the metadata, not insist that the widget developer re-write her widget to take the properties individually.

I wonder if we could wrap properties that could be bundled into an options object in some other tag? I don't have a good proposal for what that tag should be called, so I've called it <footag> in the example below:

<property name="id" datatype="string" format="id" default="jQueryUITabs" />
<property name="event" datatype="string" default="click">
<option value="click">
<label locid="event_click">click</label>
<option value="mouseover">
<label locid="event_mouseover">mouseover</label>
<footag datatype="object"> <-- not sure if we need a datatype, or it would be implicit
<property name="height" datatype="string" default="">
<option value="">
<label locid="height_fixed">fixed</label>
<option value="toggle">
<label locid="height_toggle">toggle</label>
<property name="opacity" datatype="string" default="">
<option value="">
<label locid="opacity_none">none</label>
<option value="toggle">
<label locid="opacity_toggle">toggle</label>

If we did something like this, maybe Kin's hokey template syntax would still work? (Btw, it wasn't clear to me from the <javascript> block whether the fx object was nested inside another object, of which event was a property, or whether there was a missing } or misplaced {. It might not matter, tho. :-)


Kin wrote:

As a side note, I wanted to share a problem that we’re having in describing some widgets with the current <property> syntax and macro expansion (templating) scheme.

It’s sometimes hard to describe optional properties for a constructor especially if the widget implementation assumes that the existence of the property triggers that option. For example, the tab widget allows you to specify some animation/effects during construction:

So if you want the content for the tabs to “collapse” before showing the next tab you would do something like this:

jQuery("#jQueryUITabs1 > ul").tabs({ event: "click", fx: { height: “toggle });

Or if you wanted the content to fade before showing the next tab you would do something like this:

jQuery("#jQueryUITabs1 > ul").tabs({ event: "click", fx: { opacity: “toggle” });

and if you want both:

jQuery("#jQueryUITabs1 > ul").tabs({ event: "click", fx: { height: “toggle”, opacity: “toggle” });

Now the problem we have here is that we have no way to describe, via our <property> syntax, that we only want an fx option if the user somehow specified that they wanted this collapse and/or fade behavior.

What we’re forced to do is something hoakie like this:

<javascript location="afterContent">
<![CDATA[jQuery("#@@id@@ > ul").tabs({ event: "@@event@@" @@fx@@ });]]>


<property name="fx" datatype="string" default=" ">
<option value=, fx: { height: ‘toggle’ }">
<label locid="fx_collapse">Collapse</label>
<option value=, fx: { opacity: ‘toggle’ }">
<label locid="fx_opacity">Fade</label>
<option value=, fx: { height: ‘toggle’, opacity: ‘toggle’ }">
<label locid="fx_collapse_and_fade">Collapse and Fade</label>

Where we have to present the user with every possible combination of effects just so we can write out the fx constructor option object.

Is there a better way?

The WMD spec currently lacks extra metadata that may be useful to the IDE and the IDE user, for example, off the top of my head:

- There is no way to describe what parts of the markup the IDE could repeat/duplicate to allow more tabs/panels to be added to the widget. If there were, the IDE could provide UI that could allow the user to add/remove panels without having to resort to editing the markup/code by hand.

- There is no metadata that can notate what markup is important and must be preserved, and what can be modified by the user.

These 2 issues limit the usefulness of the WMD file to inserting “blobs” of markup/code into the user’s document. Should the IDE allow editing of properties for the widget *after* insertion, it would have to re-generate the entire markup for a particular widget instance using the <javascript> and <content> templates, but then the IDE can’t just slam this new markup/code in place of the old because the user may have added markup/code *inside* the markup?

--== Kin ==--
IDE mailing list
IDE at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080821/64bb10a6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: graycol.gif
Url : http://openajax.org/pipermail/ide/attachments/20080821/64bb10a6/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: ecblank.gif
Url : http://openajax.org/pipermail/ide/attachments/20080821/64bb10a6/attachment-0003.gif 

More information about the IDE mailing list