[OpenAjaxIDE] Here are today's minutes. Also, spec has been updated

Jon Ferraiolo 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



URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008-08-19




Attendees
      Bertrand,microsoft
      Lori,aptana
      Kevin,aptana
      Jon,IBM
      Javier,IBM
      Wayne,IBM
      Kin,adobe

Minutes

onchangePattern


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.


Wayne:


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.


silence


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)


silence


Jon: OK.


Bertrand: Bye. I have to go.



macro substitution - html encoding - javascript escaping


Jon: Encoding


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"


For example:


@@entityencode(foo)@@


@@escapequotes(foo)@@


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?


Wayne: (something)


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?


silence


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.


Kevin: OK



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: Yes.


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.


(discussion)


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080819/fdf19b32/attachment-0001.html 


More information about the IDE mailing list