Gadgets Minutes 2009-03-23
From MemberWiki
URL: http://www.openajax.org/member/wiki/Gadgets_Minutes_2009-03-23
Contents |
Attendees
- Jon Ferraiolo, IBM
- Rama Gurram, SAP
- John Gerken, IBM
- Kin Blas, Adobe
- Stew Nickolas, IBM
- Adam Peller, IBM
- Howard Weingram, TIBCO
Minutes
(Reviewing http://www.openajax.org/member/wiki/OpenAjax_Mashable_Widgets)
mode Attribute
Jon: We left off on Mode attribute, now lets talk about details
Jon: Reading through detail on mode in "http://www.openajax.org/member/wiki/OpenAjax_Mashable_Widgets"
Howard: Need to add ignoring of content types == edit etc.
Jon: Does a widget that does NOT have a mode=”edit” content get notified when the agent changes the mode?
Howard: Question: Why do we need this? Can the tool to ignore a mode=”edit” and provide a common editor, that is, override edit mode provided by the widget?
Jon: A Mashup tool or IDE workflow may find it difficult to provide the property editor provided by widget (e.g. IFRAME, subdomain etc... issues, the agent is NOT rendering the widget “live”)
Howard: Seems like honoring any given mode is optional by the mashup canvas
Jon: The proposal is that the onModeChange event is fired only if you honor the widget content mode="edit", if the agent is not using the mode=”edit” content of the widget, don't tell the widget
Kin: What about Media widgets, for example, that want a chance to stop playing?
Jon: OK, the agent should trigger the event regardless then and will contain a flag in the event specifying if the agent has honored the widget mode=”edit” content
Jon: So always trigger then event
RESOLUTION: Always trigger the onModeChange event, Jon to send email with proposal for event flag name
Gadget-related issues associated with the <javascript> element
Jon: Read proposal (http://www.openajax.org/member/wiki/OpenAjax_Mashable_Widgets)
Howard: What about widgets that require things in HEAD?
Adam: That is the require tag now, correct?
Kin: Is the head stuff really necessary or matter during the runtime
Adam: The atEnd stuff
Jon: Do we know of any issues with requires? For example, does it matter where?
Adam: javascript elements are per widget instance, the requires are per widget, stuff in the HEAD has timing implications that I know of
Kin: HEAD content is loaded asynchronously
Howard: Should we create a drawing a timeline for these?...
Jon: The content and javascript elements are the same thing, ordering is an implementation issue
Jon: The require element is a "static" include
Jon: Any issues with require element?
Adam: I needed to create an onComplete mechanism in the reference implementation that messaged back to the container to know when javascript has been loaded
Adam: If the widgets are all generated inline we don't have problem?
Jon: right, onLoad handler works fine
RESOLUTION: Jon, this is all implementation specific
Gadget-related attributes on the <property> element
Jon: We have two designtime attributes, one on widget and one on property. The property on the widget element a designtime widget
Howard: As a general concept a good idea
Jon: best name for attribute?
Adam: design?
Kin: Is this property only used when you insert?
Howard: Not exactly, as the user moves in and out of edit mode, I think dreamweaver should always show
Stew: In general, from an IDE perspective the IDE always would show it
Kin: OK, so is designtime a special time?
Jon: The design time designation is really edit mode only
Howard: Ah, so designtime doesn't make sense, because its end-user only
Kin: Do we need different editing terms? runtime editing?
Kin: Can we call it editmode
Howard: So, any time the widget is rendered
Jon: yes, when you are in the browser, corresponds to mode
Howard: Let’s backup, what is the purpose of the property?
Rama: A designtime property can be changed only through the property editor NOT programmatically
Howard: OK, during design time though, a widget may have things that are highly technical not appropriate for end-users
Howard: I think of designtime as a configuration time, not end user mode
Jon: So we have the readonly and designtime for properties
Kin: This feature seems to be pure edit runtime
Howard: I believe designtime means you cannot see in mode=”edit”, therefore the property is only settable in IDE scenarios
Howard: Does widget code need to check, if the setPropertyValue succeeded or is it going to set a property?
Howard: I suggest we punt enforcement of setPropertyValue restriction
Adam: is the camel cased?
Jon: readonly is not camel cased
RESOLUTION: The designtime attribute is a hint, the agent will NOT restrict programmatically setting the value of designtime properties
2009-03-24 JON: Didn't we decide on 'designonly' instead of 'designtime'?
__WID__ macro expansion
Jon: Discuss tomorrow in IDE
Jon: __WID__ is an unquoted string, it will not refer to a variable in global scope (as it does in the reference implementation currently)
Howard: yes
Kin: classify characters?, must start with letter, etc..
Howard: more explicit
Adam: Which spec should we use?
Kin: HTML reference?
Howard: alpha (alpha numeric*)
RESOLUTION: Accepted as specified, TBD: plus a formal specification of the name.
APIs: Summary of proposed API changes
Howard: concerned about using onLoad because of HTML semantics
Jon: Understand, google uses onWidgetLoad
Howard: we need to document onLoad of widget, not page
Howard: good with naming convention, onLoad, onChange
Jon: no information passed through events
onChange
Jon: Get rid of view APIs and add mode APIs (see discussion above about the 'view' and 'mode' attributes)
Howard: widget should be able to request mode change
Howard: flexible, either way
Stew: requestModeChange API on the OpenAjax component? A request only, may not be granted given agent constraints etc. t
If jsClass not specified, then the widget instance object is a plain old Object.
Jon: Say how to create an empty object,
Adam: Could implementation have other stuff in the “plain old object”?
Resolution: Edit spec to state “A default object will be provided for you”
Jon: Any issues with Sizing and Properties, no
Start next week with XHR proxy
