IDE Minutes 2009 03-03

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Javier Pedemonte, IBM
  • Kin Blas, Adobe
  • Lori Hylan-Cho, Aptana
  • Adam Peller, IBM
  • Rich Thompson, IBM
  • Phil Berkland, IBM

Original agenda

(1) datatype=options
We OK on this now? (Except for spec editorial work)

(2) LIBRARY element (instead of REQUIRE type=library)
* Jon:

(3) Add 'lang' attribute wherever 'locid' is
(just sent before meeting)

(4) view=insert

* Jon:
Which of these is correct:
(a) view="insert" is the same thing as view="edit", except that view="insert" provides an alternate property editing UI that is used when the widget is getting added to the page. This approach would allow wizards to appear.
(b) view="insert" is the same thing as view="default", , except that view="insert" provides an alternate rendering of the widget for when the widget is first added to the page.

* Lori:
(a). We envisioned possibly using this to define the UI for a Dreamweaver object/command that inserts the widget on the page at authoring time. (Right now I think most widgets are just dropped in without the opportunity to customize them on insertion, but Dreamweaver can render HTML dialogs that appear on insertion and change what's inserted based on what's entered in the dialog.)

* Javier:
But it seems to me that (b) is more powerful, more general. It can be 
used as an alternate property editor, but also as a welcome screen, a 
login dialog, etc. It just seems that (b) is more useful, while also 
being able to handle (a)...

* Jon:
Here is I'm hearing is that (a) and (b) are two separate things and not
mutually exclusive.
<content view="edit|help|insert(a)"> represents HTML snippets that a tool
can optionally use to override their default UI for property editing, help
and widget insertion. The tool often would place the HTML snippets into a
special (sometimes modal) window that is outside (sometimes overlaying) the
widget's normal rendering.
<content view="default|insert(b)"> represents HTML snippets that represent
how the widget is rendered within the web page.
I'll point out that insert(b) can be accomplished within the widget itself
by including appropriate JavaScript logic that responds to the 'insert'

* Lori:
In Dreamweaver, the (a) scenario would have nothing to do with the widget's rendering, normal or otherwise. That is, neither of the two descriptions below cover the scenario I had in mind, though (a) comes closest. Perhaps it was a mistake to think that view="insert" could be used to support Dw extensions in a standard way, and Dreamweaver should continue to use custom, namespaced tags to represent extension UIs and supporting JS.

* Howard:
I guess I prefer (c) at this point. (Drop it altogether from this version.)

* Rich:
My preference would be (c) .... drop it. 

* Jon:
I also vote for (c), by which I mean we should remove view="insert".

(5) Adam's open source implementation of OpenAjax widgets (including mashable widget APIs)
* Jon:

(6) Concrete proposals on "Mashable Widgets"
* Jon:

(7) Status report from Lori on spec examples


(1) datatype=options

Jon: We OK on this one?

Lori: Yes. Just need to tell the jQuery engineer to modify their converter

(7) Status report from Lori on spec examples

Lori: I've been too busy to work on examples

Jon: Plans going forward?

Lori: jQuery generator only shows a handful of features. Need to use other toolkits for other features. I don't have YUI and Dojo metadata now

Jon: I can create YUI. We have an open source YUI to OAM converter.

Adam: Dojo is now generating something that is pretty close. Modeled after Aptana Scriptdoc.

Kin: Are vendors supposed to convert their own formats or use this format natively

Jon: Either. They can use it natively, or convert into it themselves, or work with IDE vendors to convert, or work with 3rd parties. We will evangelize to them that one way or another down the road they include OAM metadata in their distributions.

(2) LIBRARY element (instead of REQUIRE type=library)

Kin (after checking): We have a widget supplier that does use REQUIRE type=library. We could change our code to support both so long as we don't change the semantics

Adam (looking at Jon's proposal): The containment approach with REQUIRE inside of LIBRARY is interesting.

Jon: Seems natural to me

Adam: The other approach would be to just change REQUIRE type=library to LIBRARY and leave everything else as is. I feel I've seen more flat than hierarchical in the Ajax world

Jon: Any other opinions?

Kin: If you go with the hierarchy approach, then you don't need the 'library' attribute on REQUIRE, right?

Answer: yes

Jon: Let's not make a hasty decision. Don't need to. Let's think about it for a week and then make a quick decision a, b, or c at next week's phone call

(3) Add 'lang' attribute wherever 'locid' is

Jon: Proposal to add 'lang' on every element that contains potentially localizable text

Rich: Tells you what the inline text is so UA can either use it or replace it with a different localized string

Kin: How does this relate to %%

Jon: The 'locid' is for replacing whole elements. Mostly for DESCRIPTION, TITLE, SHORTDESCRIPTION and similar things. The 'locid' is a key into a localization bundle. The inline text is the fallback. The %%foo%% syntax is mostly for CONTENT elements where most of the content is HTML markup, which you don't want to localize, but there are substrings that need replacement, such as the content of an H3 element within the CONTENT

Adam: How would you act on the 'lang' attribute?

Rich: We consider it as part of the localization data. We found that users were copying/pasting content among widgets within global development teams, so some of the descriptive text might be in a different language than the rest of the widget.

Adam: That's interesting. I understand why it's there. I guess 'yes'. But still confused by the whole localization scheme we have.

Jon: Any other comments?

RESOLUTION: Add 'lang' wherever 'locid' is for now, but we need to do a full pass on the localization features to make sure they are good

(4) view=insert

Jon: About 10 emails, talked about how there are really two separate use cases, and ended with Howard, Rich and I saying to drop it. Any objections to dropping?

Kin: The feature is mainly for mashable widgets?

Jon: Yes, but we thought for awhile that maybe their might be an IDE use case, but that's too complicated for now.

RESOLUTION: Drop view=insert

(5) Adam's open source implementation of OpenAjax widgets (including mashable widget APIs)

Jon: Just an FYI. Adam is nearly done with a JavaScript open source implementation of the widget specs, including the mashable widget extensions. He'll update the implementation to match final decisions we make at the alliance. Might help any of you add widget support to your products with very little effort. IBM will be including it in various diverse products in the future. That will help make it more solid. Any comments or questions?

(6) Concrete proposals on "Mashable Widgets"

Jon: I sent email on this. IBM people have been doing tons of research on the mashable widgets spec and is ready to present various concrete proposals within a restart of the Gadgets TF. Will start meeting next week. The proposals are still being developed, but are solid enough for group discussion towards consensus. Any comments or questions?

Personal tools