[OpenAjaxIDE] Minutes 2009-08-25
jferrai at us.ibm.com
Wed Aug 26 08:49:40 PDT 2009
Note: Lori has already changed setProperty() and getProperty(). I have put
red-colored notes in the spec to capture the other decisions from
yesterday's phone call, but I haven't done the actual spec content changes
yet, and haven't added 'outputFormat' to the schema yet.
IDE Minutes 2009 08 25
Jon Ferraiolo, IBM
Javier Pedemonte, IBM
Scott Richards, Adobe
Kin Blas, Adobe
Bertrand Le Roy, Microsoft
Jon: I sent a proposal this morning.
Kin: Funny that the proposal did not include support for RFC 1123:
Jon: Good point
Jon: At least are we converging on adding an attribute to <property>?
Jon: OK, do we need an alternate proposal? If so, who should write it?
Kin: Will we support arbitrary formatting? Add support for everything in
Scott: I don't think so. Don't want to make more work for everybody.
Kin: Jon's proposal is fine for numeric format, we can't generate the
official parsable format
Jon: Actually, it's RFC3339. That's what we use for defaultValue.
Kin: Can we generate RFC3339 format from Jon's proposal? If so, then I'm OK
with Jon's proposal.
Scott: I would like to use the same attribute for both the input for
default value and the output format.
Jon: There is a tradeoff in terms of the widget developer. They gain
flexibility on the input side, but the spec becomes more complicated and
therefore more difficult for the widget developer to understand.
Kin: It's a lot simpler to require just one format for input. Output
formatting is more important.
Kin/Scott: If I write @@foo@@ in the file and it's a date, what goes into
the HTML file? What is the default output format?
Jon: I would say RFC3339 is the default, and put a warning in the spec
about how not all browsers and Ajax libraries support the format.
Kin: We need to illustrate the two different use cases in the spec.
RESOLUTION: Add 'outputFormat' attribute per Jon's proposal, but if not
present, then RFC3339 is used as the substituted value. No changes to how
defaultValue works for dates.
'src' and 'target'
Jon: I read Kin's email carefully. Great job. I agree with all of the main
points. However, a couple of detailed questions.
Jon: If 'src' is absolute URL, what happens with 'target'?
Kin: We assume that an absolute URL means a CDN, so we pass the absolute
Lori: Your widgets do not have 'target' in this case. What does DW do if
the developer includes 'target' with an absolute URL?
Kin: The problem is downloading assets if they specify a library or folder
because you may not be able to enumerate the children
Lori/Jon: (After checking spec) Spec says you can use 'target' with an
absolute URL, but it may not work with all developer tools. So, OK if a
tool doesn't support that feature, so DW's approach is legitimate.
Jon: Next question was the examples that refer to jQuery.js using a REQUIRE
tag instead of a LIBRARY tag. If a LIBRARY tag, then should all folders be
required to have a trailing slash on 'src'?
Kin: We assume always that a library is a directory.
Jon: I would think it is important for tools to know that it is dealing
scenario, you may not want to reload the library. Sometimes reloading a
library will mess up the rest of the application. For runtime scenarios,
you might add widgets after the onLoad event.
Jon: What do people think about jQuery.js, prototype.js and other similar
things using LIBRARY versus REQUIRE?
Lori: My question is whether you need to include version information. If
so, it's a library.
(Kin or Lori said this) You could have a LIBRARY element that point to the
folder that contains jQuery.js and then have a REQUIRE element inside that
has a relative URL to jQuery.js.
Jon: I had been thinking all along that you could have an empty LIBRARY
element with src that points directly to the jQuery.js file.
Kin: Yes, LIBRARY has all of the information you need.
Kin/Jon/Lori: In favor of requiring trailing slash on 'src' for LIBRARY if
pointing to a folder
Jon/Kin: Need to beef up the explanation.
Jon: I'm thinking of an informative appendix with examples like Kin's. I'll
Widget APIs chapter
Lori: For last sections, only minor editorial things, except for question
about 'name' attribute on getProperty and setProperty. Says Object. Should
they be String instead?
Lori: I'll change it
Metadata Overview chapter
Lori: Just minor editorial fixes.
(discussion about replacement of "APIs such as methods and properties"
being changed to just "methods and properties". Decision that this was
fine, especially given that this is just an overview chapter)
Jon: API Metadata chapter.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090826/d56fc21d/attachment.gif
More information about the IDE