Gadgets Minutes 2008-4-09

From MemberWiki

Jump to: navigation, search

Attendees

  • Stewart Nickolas <nickolas(at)us.ibm.com>
  • Rama Gurram <rama.gurram(at)sap.com>
  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Howard Weingram

Agenda

  • Widget loading/unloading interactions for static and dynamic widget assemblies
  • Trusted and untrusted models (integrating with SMash)

The interactions diagrams are located on Gadget Loading

Discussion

Stew: Introduced the interaction diagrams and the SMash integration in the attached agenda pictures Gadget Loading.

Stew: Regarding the javascript blocks for before and after content, the specification should state which scope that code executes under. In the reference implementation we execute it scoped to the gadget instance so that the "this" in the code blocks is THE instance.

Howard: Agree

Jon: Agree

Raman: Agree

Stew: So we have consensus

Jon: Does google gadgets have this?

Stew: No

Jon: Do we macro expand other resources included in the gadget? for example .js files?

Stew: No, only the metadata, in fact, only the 'content' section of the XML description of the widget (aka Widget Metadata)

Stew continued to review the SMash integration chart Gadget Loading

Howard: We need to be careful with the perceived complexity of the Hub 1.1/SMash integration and interactions. At the AjaxWorld conference I noticed during the Hub 1.1 presentation folks were concerned about the complex.

Stew: Ya, we need to make sure the complexity is hidden and the message to the gadget developer is "my code doesn't change"

Jon: Agree, we need to work on communicating the Hub 1.1/Smash integration in an easier way to understand.

Howard: We should have a best practices document that accompanies this.

Howard: Regarding navigating the DOM & Canvas we should state, SHOULD NOT

Regarding the instantiation flow in the first interaction diagram....

Howard: Step 4 (Creating the gadget wrapper) is implementation specific, we should move more of the responsibility to the wrapper class, so we have a normalized surface area (interface) much earlier in the process.

Howard: In fact, I would say you may have multiple gadget wrappers around in the same system, specifically for weird non-standards widgets

Stew: In the interaction diagram, that Widget columns morphs from the metadata description to an instance in step 4.

Howard: No good, confusing, can we introduce a separate widget instance column?

Jon: I agree, its confusing

Stew: No problem, I'll add that and attach the source of the diagrams to the page as well

Howard: In fact, I would invert the flow, that is ONLY deal with a gadget wrapper, therefore its the responsibility of the gadget wrapper to interact with A given gadget system.

Stew: Makes sense, so we'll just have a Factory for the metadata/widget systems that generates the correct gadget wrapper

Jon: The wrapper is responsible for this happening, yup

Howard: yes, for example, A gadget wrapper can implement passing the hashmap of argument values to the newly created gadget instance.

Howard: Its good the manage the properties for the gadget as a bag (hashup) as well

Raman: We still have get/set property right?

Stew: yep

Jon: Can we simply concatenate the before, after and at end text string and use innerhtml to execute

Jon: For example, Dreamweaver does this.

Stew: This approach work well for server side constructed pages, we have the additional requirement of dynamically embedding gadgets as well, unfortunately browser don't execute the script embedded in string that are placed into the innerHTML of DOM element.

Stew: The approach outlined (above) makes sense, in fact, it really how the reference implementation is structured, we just call the gadget wrapper the Gadgetspec

Howard: I'd prefer we have a consistent set of names

Stew: Not a problem, we will change

Stew: OK, I'll make the changes and we'll continue next week.

Personal tools