[OpenAjaxIDE] Minutes 2009-08-25

Kin Blas jblas at adobe.com
Wed Aug 26 10:25:54 PDT 2009


Regarding the change where the @src attribute of a <library> can now point at a JS file, does that mean for that specific case that we would need to support the @includeRef attribute which determines whether or not the IDE should insert a <script> tag for that file? There is a use case where a widget file could automatically pull in that library JS file through programmatic means.

--== Kin ==--

From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: Wednesday, August 26, 2009 8:50 AM
To: ide at openajax.org
Subject: [OpenAjaxIDE] Minutes 2009-08-25


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

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_08_25



Attendees

    *   Jon Ferraiolo, IBM
    *   Lori Hylan-Cho
    *   Javier Pedemonte, IBM
    *   Scott Richards, Adobe
    *   Kin Blas, Adobe
    *   Bertrand Le Roy, Microsoft

Minutes

date proposal

Jon: I sent a proposal this morning.

Kin: Funny that the proposal did not include support for RFC 1123<http://tools.ietf.org/html/rfc1123>

Jon: Good point

Jon: At least are we converging on adding an attribute to <property>?

Scott: Yes

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 RFC 1123<http://tools.ietf.org/html/rfc1123>?

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 URL through.

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 with a common library rather than just a JavaScript file. IN the runtime 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 do that.

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?

Jon/Javier: Yes

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)

Next week

Jon: API Metadata chapter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20090826/828f9612/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 166 bytes
Desc: image001.png
Url : http://openajax.org/pipermail/ide/attachments/20090826/828f9612/attachment-0001.png 


More information about the IDE mailing list