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

Jon Ferraiolo jferrai at us.ibm.com
Fri Aug 22 16:25:05 PDT 2008


Hi Kin,
I'll do my best here to respond. First off, in my mind, we absolutely have
to support the IDE workflow where widgets are plunked into an HTML document
at design time. Otherwise, why else would we pursue widgets within the IDE
WG?

However, we are also trying to unify widget metadata (and APIs) such that
widgets from Ajax libraries can be used both in the design-time case (i.e.,
IDEs) and the dynamic case (i.e., mashups). For example, we would like a
Dojo chart widget or a Yahoo calendar widget to be able to be loaded by an
IDE for design-time integration into an HTML application and to be loaded
by a mashup editor for runtime integration into a mashup.

For a widget to work well in a mashup workflow, it needs to support a small
number of APIs, such as responding to property change events and widget
resize events. Support for these APIs of course results in some extra work
on the widget developer who is authoring the OpenAjax Metadata markup and
associated markup in order to make the widget work optimally in a mashup
scenario.

I haven't studied all of this at the coding level yet, but my assumption is
the mashup-oriented APIs will have little effect on IDE workflows. Worst
case, it will turn out that an IDE will need to insert a small amount of
JavaScript for each widget beyond the contents of the various <javascript>
and <require> elements, such as a few lines of JavaScript to create a
wrapper object, but I would be surprised if it is more than a few lines. I
guess it is time to think this through at the code level.

Regarding my idea about requiring IDEs to include a JavaScript engine, what
I meant is a JavaScript engine that was available at design-time. I assumed
this would be no problem for Dreamweaver since (if I remember correctly)
uses HTML+JavaScript for many of its extensibility features. What I was
trying to do was come up with a (hopefully nice) solution for your problem
of multiple jQuery effects without requiring N! different property names
for all of the permutations. My proposal was that an IDE would prepare the
<content> element's content just as we have today, but at the last moment
there would be an option to run a snippet of JavaScript against the content
to produce revised content which is then inserted into the HTML. This would
allow widget developers to do arbitrarily complex last-second
transformations on the content to address difficult substitution scenarios.
OK with me if we drop this idea or if someone proposes a different and
better solution.

Jon




                                                                           
             "Kin Blas"                                                    
             <jblas at adobe.com>                                             
             Sent by:                                                   To 
             ide-bounces at opena         <ide at openajax.org>                  
             jax.org                                                    cc 
                                                                           
                                                                   Subject 
             08/22/2008 03:19          Re: [OpenAjaxIDE] Example of how    
             PM                        Adobe is using the     Widget       
                                       Meta Data ...                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Jon,

I’m a bit troubled by the responses in your original email regarding
“Complicated substitution requirements” and your reply to Lori’s “<footag>”
suggestion. The reason is that it sounds like there is an assumption being
made that all consumers of these WMD files are going to be able to execute
JavaScript and have some sort of implementation that “wraps” the widget
being described.

There seems, at least to me, to be a slant towards the support of “gadgets”
and applications/IDEs that do real-time invocation of gadgets for mashup
purposes, and real-time property tweaking of “live” gadgets, which is why I
think widget wrappers and property bags etc keep coming up in
conversations.

I see the term “widget wrapper” mentioned several times in the Widget
Metadata spec, but I don’t see it defined anywhere, or any wording in the
spec that says something to the effect that consumers of a WMD must be able
to interpret JS or have a specific implementation of a “widget wrapper”.
To me, when I hear widget wrapper, it sounds as if there is an expectation
that our IDE is invoking this 3rd party widget real-time and communicating
with it.

Perhaps I’m missing something here due to my lack of involvement up until
relatively recently, but what is the general idea behind the WMD format? Is
it a format that IDEs and Mashup editors are supposed to use to describe
widgets/gadgets, out in the wild, in terms of their own WMD interpretation
implementation? Or is it supposed to be a generic format that the widget
developers can use to describe their particular implementation which we
have no control over?

On the Dreamweaver team we’ve been assuming it was the latter, where widget
developers would simply use the WMD syntax to describe what markup, JS
code, and assets are required to create a fully functioning widget in some
random page. We don’t actually invoke the widget within the IDE, we only
follow the directions layed out by the WMD for what needs to be inserted
into a page.

Regarding your suggestion about <!--|| … || -- > I was thinking along the
same lines … processing instructions in the form of a comment that could
give helpful hints to an IDE.

--== Kin ==--


From: Jon Ferraiolo [mailto:jferrai at us.ibm.com]
Sent: Thursday, August 21, 2008 1:57 PM
To: Lori Hylan-Cho
Cc: ide at openajax.org; Kin Blas
Subject: RE: [OpenAjaxIDE] Example of how Adobe is using the Widget Meta
Data ...



Lori Hylan-Cho <lorihc at aptana.com> wrote on 08/21/2008 01:00:14 PM:

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

OK. If we want to allow multiple groups of properties, then we could allow
multiple <properties> elements, each with their own name, but I hope we can
avoid that.

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

Yes, understood.

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

There were 3 parts to my email. One of them said that there would be a
preprocessor mechanism which would receive the content of the <content> and
be able to munge it in arbitrary ways. The way the preprocessor would work
would be that the <preprocessor> element would contain JavaScript which was
the logic that did the munging. For IDEs, I was assuming this JavaScript
execution would happen at design time before the final HTML was generated.
But that's not the focus on this email.

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

I'm saying that the widget writer would include the following JavaScript
within the widget's metadata (or in referenced JavaScript files):

function foo.bar(id,wrapper) { // constructor for foo.bar class (widget's
jsClass)
this.prop1 = this.getPropertyValue('prop1');
this.prop2 = this.getPropertyValue('prop2');
}

The alternate approach would involve passing the property bag to the
constructor:)

function foo.bar(id,wrapper,propbag) { // constructor for foo.bar class
(widget's jsClass)
this.prop1 = propbag['prop1'];
this.prop2 = propbag['prop2'];
}

which doesn't not seem to be a big win for the propbag argument. Also, we
have discovered that there are other things that a widget might want to pay
attention to when used within a mashup, such as resize events or view
change events.

I am assuming that the IDE (and mashup tool) would insert appropriate
JavaScript into the generated HTML such that there was a getPropertyValue()
method on the widget's instance object. (Although I'll admit I'm not sure
at this point exactly what APIs go on the widget wrapper object versus the
widget object.)

Jon


>
> Lori
>  _______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080822/2249ac5e/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/20080822/2249ac5e/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic31417.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20080822/2249ac5e/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/20080822/2249ac5e/attachment-0005.gif 


More information about the IDE mailing list