Gadgets Minutes 2008-4-25

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2008-4-25



  • Stewart Nickolas <nickolas(at)>
  • Rama Gurram <rama.gurram(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Rich Thompson, IBM


1) onChange API - in the proposal located on /member/wiki/IBM_Widgets_proposal we have stated: ")onChange - OPTIONAL string specifying a JavaScript function or method to invoke when the property changes, if listen is true. The implementation will first check for a function within the scope of the widget and then check for a method on the widget wrapper of the specified name."

The IDE working group has asked for a proposal regarding the onChange event (/member/wiki/OpenAjax_Metadata_Specification_Widget_Metadata).

2) Languauge translation phase of the widget expansion.

The interactions diagrams are located on Gadget Loading

Diagrams for this meeting: /member/wiki/Gadget_onChange_Samples



Looking at: /member/wiki/Gadget_onChange_Samples

Stew: onChange was brought up in the IDE call yesterday. The original proposal was an onChange whenever a property is changed. When the value is changed, then the property handler is called. In the reference implementation, it is easy to implement a design pattern such as propname."ChangeHandler". Signature of the event would be propname, value.

Jon: How do you know "aTopic" event maps to the "propY" property?

Stew: It's the responsibility of the Gadget Wrapper to take care of this. The GW knows to subscribe to the right topic and then maps that to the property handler.

Jon: So the GW and the mashup canvas coordinate on an agreed-to topic for property events?

Stew: The GW knows that the mashup publishes particular events for particular property changes.

Rich: The metadata allows each property to say which topic corresponds to the property

Stew: Also, the default topic name for a property is the name of the property

Rich: The key is that you don't need to have a specialized wrapper, can read it out of the metadata

Rama: Can there be more than one handler?

Stew: As a widget writer, you could have a single handler for all properties or different handlers for different properties

Stew: One more thing about Note 2. We like to have flexibility with getters and setters, but also want widget writer to not have to write getters and setters and make life easy for them.

Stew: A main reason for onChange is that it matches how the Web works and will be understandable

Jon: So, there will be an additive processing model. If there are setters, you call them. If there is onChange, call it. Call both if both there.

Stew: Yes. Only shortcoming is the rare scenario where you want to have shared getters and setters

Jon: You can do that by just not putting any variable strings within the pattern and it falls back to a regular old callback

(discussion about signatures for getters, setters, and onChange)

Jon: Always pass both the property name and the value, both for setters and onChange

RESOLUTION Add onChange in addition to getterPattern and setterPattern

Stew: Onto the second picture

Stew: The GW implements setProperty, notices there is an event that corresponds to a particular property, and then publishes that event. Remember, we want to make it so that most widgets will not have to deal with the Hub

Stew: Picture 2 shows how the reference implementation works now. I think we should change from the reference implementation way to what is shown in the 3rd picture, and instead have the property bag implement setProperty. That way the widget only has to operate on the property bag.

Jon: Good aspect is that this approach aligns with discussions I have had with Rich in the past.

Rich: Yes, but are we only supporting simple name-value pairs or any JSON? I hope just name-value pairs.

Stew: I was hoping you could support the things we have identified in the datatypes chapter, including JSON

Stew: Here are some gotchas. Do we need to extend the lifecycle features for widgets, such as saying you are about to be persisted, or do we want to have a model where there is instant serialization without warning "about to be persisted"?

Rich: I prefer the second option

Stew: Yes, cleaner and simpler. I agree.

Jon: I don't fully understand the 3rd picture and the idea that there is logic in the property bag. Isn't the property bag just some data? What happened to the Gadget Wrapper?

Stew: Maybe the GW goes into the property bag.

Rama: Who writes the property bag implementation?

Rich: The canvas is supplying it

Stew: The implementation of the property bag is the contract with the canvas

Jon: I am thinking that a better picture would put the property bag and its logic within the GW

Rama: But we are trying to hide the GW from the widget

Rich: It is likely that there will be more things in the GW that just the property bag

Rich: Why just the property bag on the constructor?

Stew: We decided constructor takes gadget ID and property bag, and not every property has to be in the property bag

Rich: I am thinking that the default constructor is a reference to the GW. Also, in the future, there might be other services that are not related to the property bag.

Rama: I agree

Stew: I am thinking of a simple getProperties()

Rich: If services are too small, maybe put them on the GW

Jon: What have we decided on the arguments to the constructor?

Stew: It's just a reference to the GW. And then you get everything from the GW object

Rich: Can we start calling it the widget wrapper?

(agreed to change our terminology)

Jon: What is the constructor flow?

Stew: The canvas constructs the widget wrapper, which encapsulates the properties of the widget. WW calls the widget constructor, along with the widget ID and the WW. Then the WW has methods for getting and setting properties.

Rich: Therefore, property bag is never exposed, just APIs to use the property bag. I think we only need 3 APIs. getProperty, setProperty and get property names

Stew: I'll write this up and pass it around

Stew: We don't support PowerPoint on the wiki

Jon: I'll try to activate PPT


Stew: Next topic. Macro expansion for locale. Can resolve name/value pairs. eg, __firstname__. Can resolve name/value pairs from the simple localization file. Only would work on content

Jon: This aligns with Lori's proposal for macro expansion of content for inserting the values of properties. But there are other things to localize, such as 'description' tags in the metadata file. Maybe we simply add an attribute like 'localizationKey' to those elements. If you have a 'foo' label in the localization file, you would say __foo__ in the content, but localizationKey would just be 'foo'.

Stew: One last thing, is it @@ or __ or something else?

Jon: We decided on __ at the most recent IDE phone call, so that's what it is now, but we should look at JS rules and see if there is a better character which isn't allowed within JS so that we can avoid naming conflicts in case a developer actually uses __whatever__.

Personal tools