IDE Minutes 2008-01-10
Attendees this week
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Kevin Hakman <khakman(at)tibco.com>
- Phil Berkland <berkland(at)us.ibm.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Scott Richards < (at)adobe.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Rich Thompson, IBM
- Stew Nickolas <nickolas(at)us.ibm.com> (QEDWiki)
Jon: Stew checked in some things from the Gadgets work to the open source project. Stew gave online demo watched desktop as he demonstrated mashup framework where there were charts, amps, and other components, linked together through pub/sub, and under the hood, (and he could publish events to/from various controls) using OAA Hub 1.0 to do it, but did his best to take the IDE WG metadata format that’s a work in process and including a transcoder for Google Gadgets’ metadata -> XSLT -> the OAAH spec. It’s hybrid between the gadgets metadata spec and this metadata spec. But working with real-code there’s some issues that come up within a real-implementation so that Stew can point out what’s working and what’s not.
Stew: everything is checked in and there’s a how-to. We’re using this as a test bed and so that we can do thinking and code and experimentation. Going through details in IDE WG spec, their deltas are small at this time. The intent is to do some thinking and code as well.
Kevin: Thanks. What are the deltas?
Stew: Semantically everything is there. Working on values or properties? Can attributes ALSO be children tags of the widget? Allow scrolling for example … talked about making this more like Overflow with auto-scroll and the links. See preview … via sourceforge search “OpenAjax Alliance” and find the Gadgets work in process. Also links in the Gadgets wiki page.
Kevin: Anyone read or put comments into the draft spec Jon put together?
Stew: I’ve sprinkled some comments in that area.
Stew: Widget value … I see it relates to a property. Do we need a value tag to be right to the point? Is a value of a widget equivalent to a property? Also getting my head around how we pass constructor arguments to a widget? Is it a bag? It looks like we’re getting consolidated around a …
Jon: This is an area where we can be productive today…
Jon: Widget properties, values, arguments … can these be unified into a single element and have attributes that indicate this one is a “property, value or argument?”
Jon: I proposed separate elements for property and value. jMaki found it’s worth while having a separate thing as a value that can trigger onchange events, etc…
Stew: sometimes contractors have arguments with complex types.
Stew: one of the argument is the parent constructor of the associative array.
Jon: In the DW example… there’s arguments and options (options are
Jon: 2 property lists: 1 property list that get cast at instantiation time; the other controls what shows in a property inspector. In most cases those two lists are pretty much the same.
Scott: constructor arguments are usually a subset of the overall properties. Followed by getters/setters for the rest.
Jon: proposed 1 property element to service all these purposes, but then attributes for each such as “hidden”
Lori: I like that idea.
Kevin: sound like a good way to handle these cases.
Rich: is this documented in the spec?
Jon: No it’s a separate page since it’s a big topic. See properties and data types. Then the question is which properties do you pass to the constructor…each property has a default value. But then you can have instance overrides …
Lori: in Spry you can have an options object that then overrides the defaults.
Jon: one area that the metadata doc does not address yet is getters/setters and persistence of properties are important in the IDE space. So a feature in the property area we need to have property persistence with getters and setters at runtime.
Jon: Stew if you have proposals of how that might work.
Rich: portal market place deal with that – properties mare managed by the container when it wants to do persistence
Stew: what’s we have proposed is a widget wrapper – which is where that persistence is currently spec’d. The intention is thin layer to communicate with an arbitrary layer of widgets. It’s a layer for getting/setting property values. This also allows to self-discovery.
Jon: another related topic in the properties are is the list of topics published and consumed by a particular widget. Gadgets TF does this as an extra attribute on a property to identify the pub/sub.
Rich: I tend to be against this. In my experience it’s confusing for users/ Since the state does not hang-around.
Kevin: So rich you’d suggest organizing these things in a separate area in the metadata
Stew: Yes we’ve had this discussion in Gadgets. It’s trivial to do publish = true. But then also for the more sophisticated pub/sub then have added section for richer concepts.
Rich: property can become a topic.
<discussion of consolidating property names event names and sub/sub topics>
Jon: suppose we did a behavior like Google’s if there’s a property where the attribute
Rich: when you set up a property you can tell it to publish if it’s changed. But the actual publishing happens via the infrastructure.
Jon: You need topic name attribute, plus publish Boolean and listen Boolean.
- Topic attribute: default topic name is the property name – therefore could have Topic is in fact optional
- Publish attribute (Boolen) to broadcast when it changes
- Listen attribute (Boolean)
Rich: then you get edge cases, when you publish on topic a, but listen on topic B…those cases do happen, but not worth the complication at this time.
Jon: we were going to talk about the properties data types chapter in the spec next week. It’ll be worth while to walk through that and see if there’s consensus.