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

Jon Ferraiolo jferrai at us.ibm.com
Thu Aug 21 12:40:52 PDT 2008

Hi Kin and Lori,
I definitely appreciate your scenarios. Here are some thoughts and ideas:

Complicated substitution requirements
Regarding more complicated substitution requirements, what do you think
about putting in a hook that allows the content of the <content> to run
through an arbitrary bit of JavaScript before inclusion onto the page? I'm
thinking that the tool doesn't have to support a full Web browser, but
would have to support the ability to run JavaScript. This would allow a
preprocessing step that the widget itself can control. Here is some pseudo

this.myPreprocessorFunc = function(original_content) {
//munge original_content into revised_content
return revised_content;
<content preprocess="this.myPreprocessorFunc">
...original content...

I'll point out that the <javascript> object has the "this" function
pointing to the widget wrapper object.

The preprocessor function would receive the string contents of the
<content> element after the property and localizations substitutions have
occurred. With this approach, any given widget could define its own private
syntax for doing fancy things such as repeats or conditionals.

Immutable vs mutation content
Regarding some mechanism for demarking what markup can be changed by the
user, yes, I can definitely recognize that requirement. My instincts are
that we cannot require all tools to include logic that supports intelligent
partial HTML editing of the HTML snippet that is inserted into the source,
but we want to do somethign for tools that can do this. Here is a strawman
proposal. We specify the following commenting conventions:

<!--|| comment to user that tells them that they can edit this content

That would allow some tools to recognize <!--|| and ||--> and therefore
treat all of the rest of the widget markup as readonly. Some tools might
strip out the area <!--|| and the ||-->  and then present a markup editor
window that shows readonly content with a gray background and the writable
content with a white background. Other tools might choose to create an
automatic property for each occurrence of <!--|| and ||--> so that users
could supply the custom content within the property editor. I'm sure there
are several other UI approaches.

<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.


             "Kin Blas"                                                    
             <jblas at adobe.com>                                             
             Sent by:                                                   To 
             ide-bounces at opena         <ide at openajax.org>                  
             jax.org                                                    cc 
             08/21/2008 12:38          Re: [OpenAjaxIDE] Example of how    
             AM                        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

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

- 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/7eb67cf7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080821/7eb67cf7/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic10478.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080821/7eb67cf7/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080821/7eb67cf7/attachment-0005.gif 

More information about the IDE mailing list