Gadgets Minutes 2009-03-16

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2009-03-16

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Rama Gurram, SAP
  • Kin Blas, Adobe
  • Javier Pedemonte, IBM
  • Adam Peller, IBM
  • Rich Thompson, IBM
  • Howard Weingram, TIBCO

Minutes

(Reviewing /member/wiki/OpenAjax_Mashable_Widgets)

Architecture diagrams

Jon: There is one picture on the wiki page. We have a series of other pictures from the early days of the Gadgets TF which are highly relevant, but they need to be updated to reflect new terminology.

Howard's feedback

getting connection to Hub

Howard: We used to have that. Where is it?

Jon: The proposal is that it is there automatically. You have an onLoad callback, which is passed the "this" object which is the widget instance object. On that instance object there is an OpenAjax sub-object. The Hub APIs are there.

Howard: Yes, now I remember seeing that. I think it should be OpenAjax.hub.publish, not OpenAjax.publish. Don't want to mingle the namespace.

Jon: My proposal was to mingle but I'm not stuck on it.

Howard: We prevent collisions already at the top level with the OpenAjax object. It's OpenAjax.hub there.

Rich: The pointer is to the widget wrapper.

Adam: Is the OpenAjax object unique to each widget?

Jon: Yes

Howard: Can't assume it will be shared

Rich: Does the pattern that Jon propose require it to be unique? I don't think so

Adam: But people might discover the object and change the prototype

Adam/Howard: We should specify that the OpenAjax object must be unique

Jon: If subobject, should we call it hubClient? That's what it is/

Howard: Just need to namespace it "hub" and say that it is the hubClient interfaces.

Jon: What about widget APIs? On OpenAjax.widget?

Howard: Can say that APIs for this spec are on OpenAjax object. Other specs need to put their APIs on a subobject

RESOLUTION: Widget APIs on OpenAjax subobject, Hub APIs on OpenAjax.hub subobject, which implements HubClient interface

__WID__ expansion when not inline

Howard: Question: There is a statement that says __WID__ would not get expanded if inline. Why not when external?

Adam: Implementation might use browser methods and might not be able to make substitution

Javier: If inline content, no reason to disallow it. But if 'src', shouldn't do it.

Howard/Rich: Substitution should happen no matter whether content ends up in IframeContainer or InlineContainer

Howard: Which elements?

Jon: They are listed in the IDE spec

Rich: Need to also happen on CSS

Kin: Didn't we say that substitution happens on referenced content?

(Adam points out same domain restrictions)

Kin: Why you want substitution on referenced content: (1) Ability to copy a snippet from metadata file and store in external file and it works the same. (e.g., maybe the HTML snippet is quite long), (2) Ability to share HTML content across widgets

Adam: I'm OK with substitution with same domain content

(discussion about how server tunnels might open security holes)

Jon: May want to tell mashup apps to include code to disallow other domains

Adam: So, CONTENT SRC= with __WID__ in the content is OK?

Adam: But for JAVASCRIPT element, you could just insert a SCRIPT tag

Kin: If you needed to do that, why not put the SCRIPT tag in your content?

Jon: Or have a REQUIRE element

Adam: Can't stop that

Kin: Adobe treated CONTENT and JAVASCRIPT the same. Both are pre-processed

RESOLUTION: Ask IDE WG to allow substitution with 'src' on an equal basis with embedded content. Model is fetch, preprocess, and then inject into page.

Rich: I'm pretty sure this is what Lotus Mashups does

Rich: CSS also?

Jon: Applies to both REQUIRE type=css and type=javascript

Rich: Agreed

RESOLUTION: Ask IDE WG to allow substitution on REQUIRE with type=css|javascript

Three different delimiters

Howard: is there a good reason for 3 different string substitution delimiters?

Jon: No good reason

Howard: How about __category_whatever? Then you don't have to worry about inventing new punctuation characters

Adam: Also helps with regex

Jon: What has Adobe implemented?

Kin: Just the @@ syntax

Jon: What if we wanted to change that?

Kin: There were things within the @@

Jon: Oh, yeah, @@entityencode(foo)@@ and @@escapequotes(foo)@@

Jon: Let's talk about this issue in email

Remove type=page?

Adam: Didn't the reference implementation get it working, but widgets have to assume only our implementation?

Javier: Yes

Howard: Only thing you could do is a common protocol between different vendors

Howard: Easy to add new features later. If problematic, leave out of the first release

Adam: We could provide sample code that shows how to do it

Rich: That's right

Howard: I agree

Jon: Any objections to dropping?

RESOLUTION: Drop type=page

'mode' attribute

Howard: I like it. Same name found in other standards, like portlets

Jon: Any objections?

(none)

RESOLUTION: Add 'mode' attribute

Jon: We'll work out details next week

Personal tools