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

Kin Blas jblas at adobe.com
Wed Aug 20 17:50:40 PDT 2008


As mentioned in the last IDE working group meeting, I wanted to start a
thread to show others how Adobe is using the Widget Meta Data (WMD)
format since it was clear to me that others on the call were
interpreting/using properties differently. I'm hoping someone else will
do the same for the "gadgets" use case. In particular, describing what a
widget wrapper does, who provides it, and how the <properties> are used
in that scenario.

 

In a nutshell, our IDE uses the WMD file in a manner that allows the IDE
user to insert an instance of the widget described in the WMD file, into
their document with a press of a button or the selection of a menu item.
When the user chooses to insert an instance of a widget, our IDE
generates the markup/code snippets required by the widget and inserts it
into the user's document, along with all of the necessary JS and CSS
file includes. That's pretty much it. There is no widget-wrapper or
real-time communication with the widget that is placed on the page since
the IDE does not interpret/run the page as a browser would.

 

Attached to this message is a WMD file I put together that describes the
Tab widget from ui.jquery.com.

 

If you look at the <properties> section of the WMD file, you'll notice
that there are 2 properties named "id" and "event".

 

 

  <properties>

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

  </properties>

 

 

There are references to these properties within the <content> and
<javascript> sections of the document.

 

The id property is a string of format id which the IDE user or the IDE
itself will guarantee is unique so that multiple instances of this
widget can exist on the page. The event property is simply a string
which tells the Tab widget whether to show the content of a tab as the
result of a click or a mouseover event.

 

Now the way the jQuery Tab widget works, is that it expects to be passed
a selector to a <ul> on the page which contains links (the tabs). The
hrefs of these links must refer to the id of an element on the page that
contains content which should be displayed when that link is clicked.

 

Since the IDE is going to insert both the tab links and the content they
refer to, the <content> markup needs to be templated in a way that
guarantees that the markup and any ids used will not conflict with
anything else on the page. To guarantee this, I've set up the <content>
so that it generates unique ids for the tab content based on the value
of the @@id@@ property:

 

 

 

  <content>

    <![CDATA[<div id="@@id@@">

  <ul>

    <li><a href="#@@id@@-1"><span>Tab 1</span></a></li>

    <li><a href="#@@id@@-2"><span>Tab 2</span></a></li>

    <li><a href="#@@id@@-3"><span>Tab 3</span></a></li>

  </ul>

  <div id="@@id@@-1">

    <p>Tab 1 Content</p>

  </div>

  <div id="@@id@@-2">

    <p>Tab 2 Content</p>

  </div>

  <div id="@@id@@-3">

    <p>Tab 3 Content</p>

  </div>

</div>]]>

  </content>

 

  <javascript location="afterContent">

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

  </javascript>

 

 

 

So if the IDE user's document looks like this:

 

 

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Untitled Document</title>

</head>

<body>

</body>

</html>

 

 

 

Once they attempt insert the widget, they might be presented with some
UI to set the properties for the widget prior to insertion. After all
properties have been gathered, the markup/code/includes for the widget
would be inserted into the document, and would then look something like
this:

 

 

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Untitled Document</title>

</head>

<body>

 

<div id="jQueryUITabs1">

  <ul>

    <li><a href="#jQueryUITabs1-1"><span>Tab 1</span></a></li>

    <li><a href="#jQueryUITabs1-2"><span>Tab 2</span></a></li>

    <li><a href="#jQueryUITabs1-3"><span>Tab 3</span></a></li>

  </ul>

  <div id="jQueryUITabs1-1">

    <p>Tab 1 Content</p>

  </div>

  <div id="jQueryUITabs1-2">

    <p>Tab 2 Content</p>

  </div>

  <div id="jQueryUITabs1-3">

    <p>Tab 3 Content</p>

  </div>

</div>

<script type="text/javascript">

jQuery("#jQueryUITabs1 > ul").tabs({ event: "click" });

</script>

 

</body>

</html>

 

 

 

Below are some issues we've run into or noticed relating to the current
WMD spec:

 

 

 

 

The attached WMD illustrates the use case I brought up during last
meeting, which is that we need some way of specifying that the files
listed should be handled as if they are part of a library:

 

  <requires>

    <require type="javascript"
src="../jquery.ui-1.5.2/jquery-1.2.6.js"/>

    <require type="javascript" src="../jquery.ui-1.5.2/ui/ui.core.js"/>

    <require type="javascript" src="../jquery.ui-1.5.2/ui/ui.tabs.js"/>

    <require type="css"
src="../jquery.ui-1.5.2/themes/flora/flora.tabs.css"/>

    <require type="image"
src="../jquery.ui-1.5.2/themes/flora/i/tabs.png"/>

  </requires>

 

The reason we want to do this is that other jQuery UI widgets will also
require jquery-1.2.6.js and ui.core.js.

 

I believe the suggestion by Jon during the last meeting would be that we
would do something like this:

 

  <requires>

    <require type="library" name="jquery.ui" version="1.5.2"
src="../jquery.ui-1.5.2" copy="false" />

    <require type="javascript" library="jquery.ui"
src="jquery-1.2.6.js"/>

    <require type="javascript" library="jquery.ui" src="ui/ui.core.js"/>

    <require type="javascript" library="jquery.ui" src="ui/ui.tabs.js"/>

    <require type="css" library="jquery.ui"
src="themes/flora/flora.tabs.css"/>

    <require type="image" library="jquery.ui"
src="themes/flora/i/tabs.png"/>

  </requires>

 

Right? We're looking forward to the spec being updated so we can
implement these changes.

 

 

 

 

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/b3ef47ae/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jQueryTabs_oam.xml
Type: text/xml
Size: 1705 bytes
Desc: jQueryTabs_oam.xml
Url : http://openajax.org/pipermail/ide/attachments/20080820/b3ef47ae/attachment-0001.xml 


More information about the IDE mailing list