IDE Minutes 2008-04-15
- Ingo Muschenetz, Aptana
- Jon Ferraiolo, IBM
- Kevin Hakman, Aptana (chair)
- Lori Hylan-Cho, Adobe
- Phil Berkland, IBM
- Ted Thibodeau, OpenLink Software (scribe)
Ingo -- update on MixIn issue -- will submit proposal for discussion next week, based primarily on feedback from Dojo
Kevin -- question of clarification of Ancestor/s node/s - no attributes listed in spec. why not do ancestry as an attribute, rather than as node within node? Did we have reasons for this?
Jon -- doesn't remember why, but original was ancestor attribute with list of names, was switched to node within node.
Ingo, Kevin -- let's check the minutes!
... no Mixed-in node, there's Ancestors node with MixIn subelement
Class >> Ancestors node, Mixed-Ins node
Ancestors node >> Ancestors nodes
Mixed-Ins node >> Mix-Ins node
Ancestors node type == Interface or Class
conclusion -- Did this with Ancestors to be consistent with Mix-Ins
Lori -- Not sure where Jon was going with comment "don't need the various properties"
Jon -- Regarding Properties as child of Argument, for Metadata don't need to define Property. Can define a single signature for Constructors.
Lori -- Why would OpenAjax do that? Why not widget developer define their Constructor?
Jon -- Looking at jMaki, Stu's gadget stuff... maps to Constructor for given library
Jon --Tool (IDE, mashup authoring, etc) would generate HTML using a generic constructor for use with all widgets; OpenAjax would somehow then take that generic and reshape it for each underlying widget, mapping properties from generic bag to widget-specific bag
Lori -- how do we correlate properties to specific object within constructor? DreamWeaver is just trying to help users insert widgets into their page, as if they had hand-coded the insertion, through user-friendly dialog, etc. jMaki is doing very clever, but more complex extra layer...
Lori -- so each Widget author must write mapping function from OpenAjax Constructor into widget's own Constructor
Ingo -- aren't we describing Constructors declaratively elsewhere? why not do same here?
Kevin -- runtime needs of mashup environments may be more efficient with singular constructor, at author time... how does snippet-driven system of "drop this HTML into your page" map to this new constructor system?
Ingo -- we could cover 99+% of cases with declarative sytax, maybe this just leaves an escape valve
Jon -- OK with tentative decision to describe Constructors declaratively, and learn whether it works as we go...
Lori -- DW engineer has tried this already, misunderstood some correlations along the way so wasn't fully successful, but was generally fine with different widgets/toolkits
Kevin -- why is it difficult to describe constructors declaratively when we just did that with the metadata?
Lori -- Constructors aren't hard; it's with things that don't have constructors that we may have issue
discussion ... seems things lacking constructors are generally too simple to bother describing.
Lori -- this may encourage widget developers to use Constructors...and describe their stuff clearly
Jon -- key thing from Lori's proposal -- need to make association from list of properties in dialog, into property bag being passed into constructor. Format property is like Subtype property... Element = Parameter, Type = Object, Format/Subtype = PropertyBag ?
Lori -- seems like it should be fine
Jon -- next question is... You show, explicitly list properties. What if you pass 10 properties, but the constructor only accepts 3?
Lori -- email didn't include Required attribute, because none of theirs are, but ... it seems it must be included
Jon -- it's already in Widget Metadata specification of <property> element
Ingo & Kevin -- Menu in one toolkit takes a propertybag input... Properties have Getter/Setter; Fields are untouchable after the fact...
Kevin -- should we talk about these today?
Lori -- we need 'em, for certain. they can get complex, as in the example I showed -- we accept any selector for second argument for ____ widget. hard to know what that correlates to -- complex selector? ID? classname?
Kevin -- where is Selector defined?
Lori -- Selector is one of the arguments...
Jon -- where does it come from?
Lori -- Developer types it into a box, with defaults but with open-entry. if they put in a new selector, which doesn't map to the default HTML snippet, what to do? how do you handle an unknown selector?
Kevin -- widgets might have multiple instances... might have 3 GoogleMaps widgets, of different dimensions, some aspects hardcoded, some substitution variables, etc. thus might have/need different HTML.
Lori -- does IDE provide all signatures and have user pick from them? IDE pick signature from the list based on user input? do we want to allow multiple HTML snippets, and if so, how to differentiate?
Lori -- for DW, there's an author-time wrapper, no runtime wrapper
Jon -- what metadata would you put in to allow IDE to make such choices?
Lori -- yes, that's the open question...
Jon -- could have extra metadata on a content element, keywords in there, tool could do magic with keywords... gets into complexity really fast.... Returning to substitution stuff, that will be very common. jMaki has a need; Stu's proposal has it; Aptana has a concept of snippets and substitution variables; DW has a need.
Jon -- what are the details? do we have a list of standard variables, what are they, what's the syntax for them?
Kevin -- hour's ending; does one of you want to take a stab at drafting consensus proposal?
Lori -- I feel like I've already done that. General concept is that name of argument can be used to map substitution. argument to constructor called ID, when we build constructor string we insert what user provided for that argument...