[OpenAjaxIDE] Today's topics

Jon Ferraiolo jferrai at us.ibm.com
Tue Aug 26 12:44:36 PDT 2008

One of our threads this past week goes on for a long time....

Does <require type="library"> always requirea'src'attribute?.

* Jon: http://openajax.org/pipermail/ide/2008q3/000678.html?.
* Jon: http://openajax.org/pipermail/ide/2008q3/000664.html?.
* Kin: http://openajax.org/pipermail/ide/2008q3/000674.html?.
* Scott: http://openajax.org/pipermail/ide/2008q3/000675.html
* Kin: http://openajax.org/pipermail/ide/2008q3/000676.html
* Jon: http://openajax.org/pipermail/ide/2008q3/000680.html
* Marcos: http://openajax.org/pipermail/ide/2008q3/000681.html%

Example of how Adobe is using the Widget Meta Data ...

* Kin: http://openajax.org/pipermail/ide/2008q3/000660.html
- 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
- 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?
* Lori: http://openajax.org/pipermail/ide/2008q3/000661.html
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
<footag datatype="object">  <-- not sure if we need a datatype, or it would
be implicit
  <property name="height">...</property>
  <property name="opacity">...</property>
* Kin http://openajax.org/pipermail/ide/2008q3/000662.html
* Jon: http://openajax.org/pipermail/ide/2008q3/000663.html
(A) this.myPreprocessorFunc = function(original_content) {
//munge original_content into revised_content
return revised_content;
(B) <!--|| comment to user that tells them that  they can edit this content
(C) this.getAllProperties()
* Jon: http://openajax.org/pipermail/ide/2008q3/000666.html
* Lori: http://openajax.org/pipermail/ide/2008q3/000665.html
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?
* Jon: http://openajax.org/pipermail/ide/2008q3/000666.html
(1) we could allow multiple <properties> element
(2) I'm saying that the widget writer would include the following
within the widget's metadata (or in referenced JavaScript files):
function foo.bar(id,wrapper) { // constructor for foo.bar class (widget's
      this.prop1 = this.getPropertyValue('prop1');
      this.prop2 = this.getPropertyValue('prop2');

* Kin: http://openajax.org/pipermail/ide/2008q3/000677.html
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.
* Jon: http://openajax.org/pipermail/ide/2008q3/000678.html
(A) 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
(B) what I meant is a JavaScript engine that was available at design-time.

IDE design-time workflows and widget APIs
* Jon: http://openajax.org/pipermail/ide/2008q3/000683.html

Gadgets TF requests restoration of onchangePattern

* Jon: http://openajax.org/pipermail/ide/2008q3/000667.html
* Bertrand: http://openajax.org/pipermail/ide/2008q3/000668.html
* Jon: http://openajax.org/pipermail/ide/2008q3/000669.html.
* Bertrand: http://openajax.org/pipermail/ide/2008q3/000670.html
So how about the default (and only) pattern is using a unique function? If
your internal implementation is using onFooChanged patterns, you’d
implement it like so:
MyWidget.prototype.propertyChangeCallback = function(propertyName, value) {
                this[“on” + propertyName + “Changed”](value);
* Rich: http://openajax.org/pipermail/ide/2008q3/000672.html;
* Bertrand: http://openajax.org/pipermail/ide/2008q3/000673.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080826/02ca7e63/attachment.html 

More information about the IDE mailing list