IDE Minutes 2008-04-15

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008-04-15

Contents

Attendees

  • Ingo Muschenetz, Aptana
  • Jon Ferraiolo, IBM
  • Kevin Hakman, Aptana (chair)
  • Lori Hylan-Cho, Adobe
  • Phil Berkland, IBM
  • Ted Thibodeau, OpenLink Software (scribe)

Minutes

MixIn issue

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!

Discussion --

... 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


Widget metadata

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...

Jon -- have to have list of Properties, their Types, Default Values, etc. Pretend we have a standard Constructor, no matter what library you have, with simple argument which is Object, that being name=value pairs for all Properties, lacking any Property using default value. Given library's Constructors look different, and therefore include JavaScript element which does mapping from OpenAjax Constructor into library's own Constructors.

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?

Jon -- many simple widgets won't use constructors at all. toolkits will typically have constructurs, with a snippet of HTML content, as well as some JavaScript; the latter would have standard classname (e.g., OpenAjaxGadgetWrapper), which would be invoked... This is to cover the world that doesn't cover everything with declarative syntax

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?

...discussion...

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

...discusison...

Ingo & Kevin -- Menu in one toolkit takes a propertybag input... Properties have Getter/Setter; Fields are untouchable after the fact...

Substitution variables

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?

...discussion...

Jon -- fallback is always runtime Javascript wrapper

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...

Personal tools