Gadgets Minutes 2009-03-16
From MemberWiki
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