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

Kin Blas jblas at adobe.com
Thu Aug 21 00:38:33 PDT 2008


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" />

 

<options>

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

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

</options>

 

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

  <options>

    <option value="click">

      <label locid="event_click">click</label>

    </option>

    <option value="mouseover">

      <label locid="event_mouseover">mouseover</label>

    </option>

  </options>

</property>

<footag datatype="object">  <-- not sure if we need a datatype, or it
would be implicit

  <property name="height" datatype="string" default="">

    <options>

      <option value="">

      <label locid="height_fixed">fixed</label>

      </option>

      <option value="toggle">

        <label locid="height_toggle">toggle</label>

      </option>

    </options>

  </property>

  <property name="opacity" datatype="string" default="">

    <options>

      <option value="">

        <label locid="opacity_none">none</label>

      </option>

      <option value="toggle">

        <label locid="opacity_toggle">toggle</label>

      </option>

    </options>

  </property>

</footag>

 

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

 

cheers,

Lori

 

 

Kin wrote:

 

<http://openajax.org/pipermail/ide/2007q4/000170.html> 

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@@
});]]>

  </javascript>

 

...

 

  <properties>

    ...

    <property name="fx" datatype="string" default=" ">

      <options>

        <option value=, fx: { height: 'toggle' }">

          <label locid="fx_collapse">Collapse</label>

        </option>

        <option value=, fx: { opacity: 'toggle' }">

          <label locid="fx_opacity">Fade</label>

        </option>

        <option value=, fx: { height: 'toggle', opacity: 'toggle' }">

          <label locid="fx_collapse_and_fade">Collapse and Fade</label>

        </option>

      </options>

    </property>

    ...

  </properties>

 

 

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080821/8911687e/attachment-0001.html 


More information about the IDE mailing list