[OpenAjaxIDE] Minutes today 2007-12-13

Jon Ferraiolo jferrai at us.ibm.com
Thu Dec 13 13:27:31 PST 2007

Thanks to Lori for taking minutes while under the weather.

IDE Minutes 2007-12-13

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2007-12-13


Kevin: Has anyone done any further work on trying to write up...?

Stew: I did a mapping/diff between the Gadgets Metadata Strawman proposal
and the Widgets Metadata Strawman that Jon wrote up. Took a Google Gadget
xml and transformed it into OOA Gadget Metadata.

Jon: Eventually we'll probably want to unify these strawman proposals,
since there's a lot of overlap.

Stew: [Something about the adapter.] Words are great, but you need to test
it out as you go.

Kevin: Gadgets tend to be mini-applications, whereas controls are more
standalone and still have to be configured, programmed, instructed what to
do. The Gadget work seems to be focused on a kind of runtime assembly,
whereas the Widget/Control work is more around how to let a tool help a
developer rig up a control.

Jon: ...are gravitating toward an approach that would allow for a
unification of the different proposals. They're leaning toward constructors
and divs with IDs and so on.

Kevin: On the subject of similarities and differences, Stew, can you talk
about how the Gadget work relates to the Open Ajax Hub?

Stew: The Gadgets proposal we're coming up which can run on top of the Hub.
[Didn't get all the details -- sorry, sick brain is fuzzy. :( ] Default IDE
is a text editor. Grain size (?) of gadgets tend to be a little larger, but
we're hoping to use the same metadata as we go up the chain. Gadgets need
to have sort of a closure for security reasons. We anticipate that widgets
will move around from one hosting environment to another. The pub/sub model
is similar to how Google Gadgets have done their....?...when you want to
publish a property value, you put publish=true or listen=true. All of this
will boil down to a reference implementation that will run on the Hub.
Using the eventing model of the Hub as well. Plugging into the Hub is very
important and putting together a reference implementation is important as

Jon: So what this boils down to...

Stew: Semi-aligned with the Aptana approach with bag of properties.
Constraints... let's think of backing off of developing a new kind of
constraints and falling back to an xsd tool. Balancing a rudimentary
property editor vs. letting the Gadget edit itself.

Jon: I wrote up this thing with jsType and xsdType, but we haven't really
had any discussion around it, and a few people have objected to it. So
that's wide open right now.


Jon: I think the whole datatyping issue needs more focus. We should have a
meeting that's dedicated to issue #2.

[Some discussion about whether typing is really issue #2. May need to add
another issue.]

Stew: So we're sort of punting on datatypes for now; we figured we could
add something more elaborate later.

Jon: What do the IDE folks think about this?

Lori: Strings can obviously be text fields, but the type of string can
really get you into trouble (IDs that must be unique, selectors that mean
something, etc.)

Kevin: Plus, enumerations.

Scott: Exactly -- enumerations are really important.

Jon: It seems like there should be a fallback approach. If the metadata has
too much information, the IDE doesn't need to use it; it can fall back to
the main type.

Bertrand: We absolutely must have support for enumerations, arrays, etc.,
but it also seems like we need an extensibility mechanism.

Phil: What about just having a snippet of JS code that validates the value?

Bertrand: That doesn't help the user ENTER the value, though. You might
want to have a collection editor, for example, that makes entering the
value easier.

Jon: I can look into this and see if there's an answer that jumps out, and
I can have that for next week.

Kevin: I think next week we can start diving into the individual topics. Or
maybe now, since we have 20 minutes left.

Jon: Let's start with issue #1, since it was talked about a bit yesterday
in the Gadget TF. [Jon walks us through The New Proposal in the issue #1
wiki page.]

Discussion about whether head="" covers the cases we want, and whether
insertAt="head|body|null" would be more appropriate.

Kevin: What about the order in which the assets are referenced?

Lori/Scott: We assumed that the order specified would be the order added.

Stew/Kevin discussing whether "head" means PUT IT IN THE HEAD or the more
generic PUT IT IN MEMORY FIRST. (Memory seemed to be the consensus.)

Stew: We need some way of sandboxing widgets, of saying that this widget
cannot co-exist with some other widget with, for example, a different
preload setting.

Jon: Yes, we do.

Stew: So we need metadata that could describe this sandboxing requirement.

Kevin: Can you take a stab at that?

Stew: I think it boils down to knowing when to create an iframe.
ineedaniframe = "true" is one way, but you could also be reactive and let
the tool say, "you've already got a gadget that has preload = false, so
this one with preload = true needs to go into an iframe."

Kevin: I'm a little nervous about having 50 require statements for all the
bits and pieces that a widget might need to run.

Jon: I think in that case you'd just point to the dojo or GI folder, rather
than all the individual files, and let your application indicate which
files from the toolkit it requires.

Kevin: So we are meeting next week on Dec. 20, and we'll talk about the
datatyping issue. We'll skip Dec. 27 and meet again on Jan. 3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071213/9f14d07c/attachment.html 

More information about the IDE mailing list