Gadgets Minutes 2009-03-23

From MemberWiki

Jump to: navigation, search

URL: /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 /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 "/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 (/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

Personal tools