Markup Minutes 2006-07-27
From MemberWiki
Contents |
Minutes from Declarative Markup committee teleconference July 27, 2006
Attendees
- Phil Berkland <berkland@us.ibm.com>
- Jon Ferraiolo <jferrai@us.ibm.com>
- Lindsey Simon <lsimon@finetooth.com>
- Ted Thibodeau <tthibodeau@openlinksw.com>
- Alex Russell <alex@dojotoolkit.org>
- Vivienne van der Vooren <vvandervooren@seagullsoftware.com>
- Anil Sharma <anil@vertexlogic.com>
- Dave Johnson <djohnson@ebusiness-apps.com>
- James Margaris <jmargaris@nexaweb.com>
- Coach Wei <coach@nexaweb.com>
Absent
- Adam Peller <apeller@us.ibm.com>
- Alejandro Escalante Medina <alejandroe@jackbe.com>
- Brodi Beartusk <bbeartus@bea.com>
- Charles Lowell <cowboyd@thefrontside.net>
- Chris Jolley <jolleyc@bea.com>
- Chuck Ames <CAmes@seagullsoftware.com>
- David Frankel <david.frankel@sap.com>
- David Temkin <temkin@laszlosystems.com>
- Eddie O\'Neil <ekoneil@bea.com>
- Eric Nguyen <ericn@mercedsystems.com>
- Erik van Dongen <evandongen@seagullsoftware.com>
- Gustavo Munoz <gustavom@jackbe.com>
- Javier Gallego <Javier.Gallego@softwareag.com>
- Jeremy Chone <jchone@adobe.com>
- Jim Grandy <jgrandy@openlaszlo.org>
- John Crupi <john.crupi@jackbe.com>
- Joonas Lehtinen <joonas.lehtinen@itmill.com>
- Jorge Taylor <jotaylor@adobe.com>
- Ken Fyten <ken.fyten@icesoft.com>
- Kin Blas <jblas@adobe.com>
- Kingsley Idehen <kidehen@openlinksw.com>
- Marc Englund <marc.englund@itmill.com>
- Mark Schiefelbein <mark@backbase.com>
- Michael Peachey <mpeachey@tibco.com>
- Ruben Daniels <ruben@javeline.nl>
- Sami Ekblad <sami.ekblad@itmill.com>
- Steven Pothoven <pothoven@us.ibm.com>
- Vincent Hardy <vincent.hardy@sun.com>
- William Shulman <will@mercedsystems.com>
Agenda
- Markup Scanner - The main focus of the meeting will be reviewing James Margaris's JavaScript and HTML test files that represent initial steps towards implementing the markup mixing features of the OpenAjax Hub
- Markup Mixing Nexaweb IBM 20060726 - We may not get to this document due to spending most/all of the time on James' contribution, but if we do have time, this document attempts to capture current committee thinking on markup mixing issues. (This document is still being updated and might not be complete until just before the meeting.)
Minutes
Jon: Lets look at James sample on the wiki
James: introduces the sample code, represents comments from Anil, difference from before is scanning for ids, Scans for ids instead of the whole document
James: This just looks for "oatype", not for class or xml-style namespaces tags, will do this, doesn't affect the functionality, differences in the test files is between is manual recursion vs no recursion, it is upto the handler to recursive
Jon; Agrees handlers have to do recursion, OpenAjax hub wont recurse automatically
Alex : There should be plugable handlers or names, and other combinations attributes names, test function applied to nodes
James: yes, there should be a generic test handled by toolkit
Jon: Callback function registered by toolkit, when new element reached, hub calls function saying you check
Jon: will have a trade-off between new features and being lightweight,
Jon: Will a make list of options to be considered for next meeting
Jon: goal is to minimize change to existing content
James: a handler callback is trivial to add
Jon ; Lets talk about the issues at bottom of the wiki page, What if 2 toolkits both have a 'redbutton' , this conflicts, needs namespace, James said oatype value supports colon, said the value should be toolkit name
Alex : would that be a 2nd attribute
James: 'oatype' indicates toolkit specific name, ie 'dojo', scanner wants to know what toolkit handles that tag
Jon:
Alex: 'redbutton' replaces with toolkit,
Lindsey: Will need to register names for toolkits so there are no collisions
James: we will have to do that
James: 2nd issues: XPath issues, more generic way to identify things, not that efficient to write or run XPath, likes the idea of a callback instead
Jon: It is not hard to implement multiple options, except for XPath, callback ,check for a specific attribute, generic, we can implement and get feedback from our own group and public instead of making choice now, put options out there and make choices later
Jon: is the attribute value a toolkit name, widget name, or some combination,
James: toolkit name
Jon: toolkit needs to know what node is
Viv: that's an attribute within tag, oatype is attribute within the tag
Jon: most of the time, the tag is 'div', if tagname dojo:combo will know, but wont if using class or type
Alex: toolkit will have their own identification
Dave: from a component venders standpoint, better to have toolkit and component, fits better with xml namespace
Jon: sounds some want one way, others, need to
James: something simple like substr after : can do oatype="dojo:ss", if colon, it is toolkit name
Anil: OK
Jon: there is a transition world will go thru, right now, XML Namespaces not available thru IE, IE doesn't support 'getAttributeByNS()', just partial support, IE will support XHTML proper, future is proper XML namespaces, but today there isn't,
Jon: register toolkit name, best practices is to register prefix, backward compatible must match what scan for every toolkit will provide unique id, register toolkit, hub should throw runtime error if duplicate toolkit names, will write up some samples
?: yes
Jon: Alex mentioned callback , comments on issues flexible scanning?
- none -
Jon: on issue 3, should the name be 'openajax' or 'oa'
Alex: oaa
Viv: more readable with longer name but more typing
Anil; openajax, is much clearer, oa can represent other names (i.e. office automation)
Jon: from a marketing perspective, we are trying to establish an OpenAjax brand, trade-off with longer typing
Ted : more chance of collision with shorter name
Alex: main concern is another toolkit already using that name
Jon: not just current members, will be more, will be many more toolkit vendors, if we don't conflict with any known today, we can reserve anything we want, there will be no collision issue if we do our research, more of a style issue
Coach: look at enterprise developer, not as experienced with AJAX, much better to have it spelled out, long api names, better for code maintenance
Jon: good points, use openajax for now, get a feel for how cumbersome and verbose it is
Resolution
we will use 'openajax'
Jon: 4th issue - where is scan done, put in onload, can control where scan is done, maybe should only allow procedural approach, comments?
James: we want to play nicely with multiple toolkits doing "onload", more flexible if registered with hub for onload
Alex: there is an event hub
James: would like to merge with event hub, (not separate file) have it rely on event hub for onload
Jon: why not merge the files?
James: including page scanner is implicit permission to do page scan,
Jon: down the road we want to have a single OpenAjax alliance hub, for now, louse coupling is fine,
Alex: until we host under oaa, is mute
Jon: openajax markup scanner gets kicked-off at loadtime, toolkit don't register load event with browser, but with event hub, one level of indirection, any objections?
Alex : policy should toolkit should be non destructive, preference is OpenAjax hub
Jon: how are you non destructive without the hug
Alex : build a closure, calling previous handler, cant stop user from doing onload, which raises another question, should it be done on onload vs onDomLoad?
Jon: which is first,
Alex: domcontentloaded is first, advantage is not many are using it,
Jon: what hasn't happened yet when DOMContentLoaded
Jon: images not loaded,
Jon: should allow developer to decide when scan occurs, we should choose default
Alex: developer is getting OpenAjax as part of the toolkit they are using, not really aware of OpenAjax
Jon: developer will be toolkit centric, since current toolkits do onload
Alex: openajax Object provides services to toolkit vendor, not develop
Coach: toolkit vender decides when to use OpenAjax
Alex: don't destroy openajax if exist, defer to openajax event hub
Coach: if calling 2 toolkit initialize, openajax hub is encapsulated within toolkit initialize
Alex: markup hub handles tag handling
James: goal is naive developer just use toolkit, scan is done by default, configure to not run is allowed.
Jon: in the example, script tags include openajax, toolkit1, toolkit2, should there only be 2 include? is openajax include needed?
Alex: toolkits carry openajax hub, toolkit includes openajax, possible versioning problem, should be handle by interop group
Jon: we should evangelize to toolkit vendors to include OpenAjax in toolkits, developers knows about OpenAjax brand and checks if toolkit is valuable
Jon: "OpenAjax inside", just like "Intel inside"
[The following people said they would help incorporate the OpenAjax Hub into existing Ajax runtime libraries]
- Lindsey Simon <lsimon@finetooth.com> - Prototype
- Ted Thibodeau <tthibodeau@openlinksw.com> - OpenLink
- Alex Russell <alex@dojotoolkit.org> - Dojo
- Anil Sharma <anil@vertexlogic.com> - presumably AjaxFace Client
- James Margaris <jmargaris@nexaweb.com> and Coach Wei <coach@nexaweb.com> - presumably XAP/XAL/Nexaweb
[Jon pointed out that TIBCO seems like a likely candidate, given their implementation of Alex's May 24 submission]
Action Items
- James continues development
- will change example to reflect toolkit name
- will add generic toolkit check handler
- will use wiki page as source repository for now
- will go into mainline dojo
- openlink will participate
- Jon will talk to Scriptaculous (Thomas and Sam)
