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

Lori Hylan-Cho lorihc at aptana.com
Wed Aug 20 19:04:56 PDT 2008


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/20080820/4b808018/attachment-0001.html 


More information about the IDE mailing list