[OpenAjaxIDE] Here are today's minutes. Also, spec has been updated
jferrai at us.ibm.com
Tue Aug 19 18:18:57 PDT 2008
Below are minutes from today's phone call.
I updated the spec to reflect today's decisions, but in some cases I only
tossed in some colored comments that captured the decision and left the
wordsmithing until later.
Here are the minutes.
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
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
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
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
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
Jon: I'll put together a widget from an Ajax library from the reference
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
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,
<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
Kin: OK. Let's get it in the spec.
Jon: I'll make some edits right away, then do writeups for scenarios later.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE