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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080822/d3ea0895/attachment.html