IDE Minutes 2008-08-19
Bertrand: onChange? Where will this be used? Mashup only or also IDE?
Jon: onChange was only in mashups.
Bertrand: That would suggest that the widget would write a short proxy for the event which I suppose is OK in mashups. So in my email I was reacting to this. But in the case of mashups I suppose it's OK. But in this case do we need the pattern at all? Can we just ask them to adhere to a pre-defined pattern?
Jon: Wayne? Javier? In regard to the email you sent suggesting one could use the onChange, why not follow what Bertrand suggesting as to not having an attribute and just have a standard pattern.
Bertrand: I was confused earlier. Now that this is for mashups only, I'm good with onChange.
Wayne: I felt like it was a good point Bertrand made. I'm fine with that
Bertrand: We shoud accomodeate all patterns, or pick one. In the case of API metadata I think you do not want specific code, in the case of mashups it's different.
Kin: Can you calrify. Is that in a mashup editor when a property changes, then a message gets sent.
Bertrand: If you want to connect the property of one widget with the property of another widget.
Kin: This is for near to real-time communication.
Jon: I think both Kin's and Bertrands scenarios are correct. If you change a property then it triggers the event. If properties are linked, then onchange is triggered at both.
Jon: Then we do not need an onchange attribute for the mashup scenario. So I'd propose dropping this attribute for the mashup sceanrio.
Wayne: Fine by me.
Jon: Then we need a name for onChange callbacks for properties, and we shoud let the gadgets taskforce do that.
Jon: What about in the IDE scenario
Kin: Adobe's paradigm is more about code instertion, so we do not need it.
Kevin: I do not see a core need for the onChange pattern
Jon: So the resolution is that we drop the onChange pattern alothgether (until someone says they need it)
Jon: next topic
id attribute for unique widget id
Bertrand: fully qualifying the ID attribute.
discussion amongst Jon, Kin, Bertrand, …
Jon: Proposed resolution: ID attribute required on widget element; takes a URI; and the URI is supposed to uniquely identify the widget (the same approach as the W3C Widget spec takes)
Bertrand: Bye. I have to go.
Jon: Lastest think is @@foo@@ and if you od (js) or (html) indicates that extra processing is required on the element.
Kin: Perhaps say entity encode or escape characters.
Kin: Use case is including quotes delimiters
Jon: " ' and / for JS and < > & " ' for HTML
Jon: Does anyone object to the feature of having parenthetical expressions wihtin the @@ delimiters.
Jon: Entity encode and escape quotes makes sense to me.
Wayne: I like it in the front.
Lori: I like the front too.
Kin: It's easier to see
Jon: We can also put it in function syntax
Lori: that's what I was thinking.
Wayne: I see. Like you’re calling the HTML cares FN on the remark.
Jon: does anyone object to "entityencode" "escapequotes"
Jon: So an implenter would match "@@escapequotes(" then ")@@"
widget constructor property bag
Jon: Next: Widget contructors with a property bag not being passed. I think that's a gadgets taks force issue. Should we just let them deal with that tomorrow? Or discuss it now?
Jon: Howard wanted to talk about it.
inline message bundles
Jon: OK, next topic: Rich Thompson of IBM talking to product teams, heard about the number of HTTTP GETS to make internaltionalization work. So they requested an optimization where the message bundles could be in the file directly. This could be implemented at the server by a process that inserts the needed bundle into the metadata file just before it gets sent to the client.
Jon: Does the message bundle element need a namespace on it? If we just do string insertion, then we inhereit the namespace of the parent element.
Jon: The second thing is that you need to say which language it is when its inline. So I propose a lang attribute to indicate language (en_all would be used if the bundle was en_all.xml for example)
Jon: Any comments?
Jon: Any objections?
Jon: I'll email the prposal to Rich and if he's good with it, then we'll incorporate it. OK?
Wayne: I second that.
macro substitution details
Jon: Next: Macro substitution details
Jon: When wayne and he were implemented the spec, they realized that the spec was not clear about all the cases. Javier wrote up a proposal which was emailed to all re: which ones are subject to %% and @@ and __WID__ variable that the gadgets guys use. There's an email wht the proposal in it? Did anyone look at that email?
Kin: Why would that not just be another property?
Jon: This is the JS object name. Let's say you have alcok widget and you put two there on your page. When you instance the class you have 2, thus the __WID__ is the name of the object relative to the window object to handle a bootstrapping issue where you have to be able to go find where you are.
Kin: That's identical to our use case as well.
Jon: I think it's a different bootstrapping issue in your case. But in the mashup at runtime.
Kin: it's be good to see in the spec for tags and attributes that are specific to a single use case (e.g. Mashup or IDE)
Jon: Ther are scenarios where you want the metadata to work both in Mashup and IDE scenario.
Kin: It might be helpful, at least to me, to share the widget metadata file so that we can see how the IDE interprets the files.
Kin: I'll start a thread offline as to how it gets inserted into a users document.
Jon: I'll put together a widget from an Ajax library from the reference implementation.
Jon: I'll put together an email with a link to the refernce implementation.
Jon: Anyone see any problems with the list of where substitutions happen.
Kin: One question is WHEN those substitutions happen. That should be specified as well.
Jon: I'll look into that and send an email if any issues arise that I can see.
JSDoc to OpenAjax Metadata converter
Jon: I did a JSDoc converter to transform JSDoc format into OAA format. I got all the majors implemented, but had questions about field v property, etc…
<require> and sharing assets across libraries
Jon: Kin was asking if we completed our discussion about the library attribute so that shared assets could be defined across multiple widgets.
Lori: I thought we had a way to say these file are part of a library.
Jon: We had a copy attribute, then we got rid of it.
Kin: We had library with a library name. So can you use that without defining a library to give a hint that this was a shared file.
Jon: But there was no definitive statement there.
Kin: We'd need an explicit list of files upon which for example a dojo.slider would depend so that we need not copy the whole library.
Kim: We also need min version, max version.
Jon: I think I agreed with you, but I lost tack. I think you convinced me.
Jon: So "min version" becomes "version". So does that take core of this issue.
Kin: OK. Let's get it in the spec.
Jon: I'll make some edits right away, then do writeups for scenarios later.