IDE Minutes 2008 07 22

From MemberWiki

Jump to: navigation, search



  • Rich Thompson, IBM
  • Lori Hylan-Cho, Adobe
  • Stew Nickolas, IBM
  • Phil Berkland, IBM
  • Jon Ferraiolo, IBM

Email for background of the discussion

NOTE: Below is the email Jon sent regarding the first part of the discussion:

One of the open topics from this week's phone call was a response to Lori's email (

... So, given the above, I have a couple questions:

1. What exactly is meant by "loading"? Does it mean that the IDE would not add the same file to the head twice? If so, I think we can handle that part. If, however, it means that the same asset should not appear in multiple places in the user's site, that's a problem. I'm hoping it's the former, but that still brings up point 2:

2. How would we know whether the dom.js file that's included with the FooCalendar widget is the same dom.js file that's included with the FooPassword widget? Is there some assumption we should be making here, in the absence of any indication that FooCalendar and FooPassword are actually part of the same library? Would the expectation be that dom.js be specified with <require type="library" src="dom.js">, and that this is how one would indicate "shared" files? If this is the case, then it seems to me that the name attribute (the name of the library) and possibly the version attribute might still be required in addition to src to help determine whether the file in question really is the same as another file of the same name.

I studied a few major toolkits and thought things over. One observation is that it appears that major Ajax libraries support a workflow where you copy their entire Ajax library onto your Web site, which potentially wastes disk space on the server, but they all have modularization techniques such that when your web page runs, only the modules that your web page needs are downloaded over the wire. For YUI and ExtJS, the standard way of pulling in only those modules that you need is to manually insert script tags for those modules. For Dojo, there are multiple advanced options due to their build system, but the "normal" way of using Dojo is to include a script tag for "dojo.js" and then call "dojo.require(...)" to identify the modules that you need, and then Dojo will pull in those modules for you. (I believe the normal approach for Prototype and jQuery, which are relatively small, is to simply source in the single JS file that contains the whole library.)

Here is what I am thinking:

1) We don't need a 'shared' attribute. Instead, if 'name' is supplied, then that indicates that an asset is subject to sharing.

2) As Lori suggests above, if type="library", then a properly constructed metadata file SHOULD include a 'name' and a version attribute so that tools can determine shared usage of the same library and install it only once within the distribution directory structure. (Note: I have questions about 'minVersion' below in #4 below. Regarding 'folder', see #7 below.)

3) As Lori suggested in the phone call, from a processing model perspective, 'library' and 'folder' amount pretty much to the same thing: a copy operation on a folder. In fact, the 'name' attribute might make sense for 'folder' even when referring to something that isn't a JS library so that a particular folder can be shared across multiple widgets. (But before getting too far in that discussion, we need to talk about 'minVersion': see #4 below.)

4) But now onto 'minVersion'. I am wondering what we really need from a version attribute. Do we need to identify which *range* of library versions that are compatible with this widget, or do we need to specify what *exact* version number is for the library that is referenced by the 'src' attribute, or both? There are usually too many dependencies between widgets and libraries such that a particular widget will often only work with only one particular version of a library, or (for widgets defined by a 3rd party on top of a particular library) a particular generation of a library (e.g., Dojo 1.1.x). Here is what I suggest we do - two version attributes for <require type="library">:

  • 'version' indicates the exact version number for the library that is referenced by the 'src' attribute. For example, if the 'src' attribute references Dojo 1.1.2, then the element would look like:

<require type='library' name='dojo' version='1.1.2' src='...' />

  • 'compatibility' indicates the range of library versions with which the widget is compatible. For example:

<require type='library' name='dojo' version='1.1.2' src='...' compatibility='1.0-1.1.2'/>

5) So that widgets will use a standardized approach to library names, the 'name' attribute for a library should refer to a registered name with the OpenAjax Registry.

6) We need to have a well-defined processing model if attributes 'name', 'version' or 'compatibility' is missing. One option is to treat as an error, but error situations are usually messy, and usually better to figure out defaults for missing attributes. Here is my proposal:

  • If 'name' or 'version' is missing, then there is no sharing. (The spec would need to include strong recommendations about having 'name' and 'version' attributes and include warnings about potential file duplications and potential file collisions if these attributes are not supplied.)
  • If 'compatibility' is missing, we default to the range 0:infinity.

7) As I mentioned in #1 above, 'library' and 'folder' are very similar and in fact could probably be merged. My proposal, however, is to have two separate keywords because of the semantic value of the word 'library', but otherwise the two options share the same attributes and have the same processing model. Therefore, it is possible to use 'name', 'version', and 'compatibility' on a 'folder' (although for type='library', the 'name' attribute does not have to refer to a name from the OpenAjax Registry). The spec would point out these similarities and tell metadata authors to use 'library' when referring to an Ajax library and use 'folder' when referring to a folder that isn't an Ajax library.

8) I think it makes sense for 'name', 'version' and 'compatibility' to also work with the other types (e.g., type='javascript') so that a tool can deal with sharing of individual files, not just folders.

I am not sure the above addresses all of the issues that Lori brought up on Tuesday. Lori, what did I miss?



Jon: Lets talk about email regarding requires

Jon: Seperate tags for copying AND putting things in the head.

Lori: I'm worried about one widget's requires tag, overwriting another widgets files that are "just" included

Jon: Lets talk about the target attribute, have you implemented?

Lori: Yes, we've implemented, following current spec, no problem

Lori: Sharing of files, site vs. document relative is a problem.

Jon: Lori can you make a proposal?

Lori: The direction Jon was headed sounded good (above)

Lori: We need a very explicit list of required files to be included in head as well as files that are required but not referenced in head

Jon: Require puts something in the head or script include.

Jon: Worst case scenario, attribute on require to copy or not? copy true or false, deploy? on the require tag

All: Agree on the requires attribute on the require tag, copy default value is true copies the file into the deployed package

== childProperties ==
Jon: 2008-07-23 Phil has proposed a <childProperties> element, such as when a child element needs to pass information to parent to help control layout. I have done some due diligence on this. It is common that layout containers utilize some sort of "property" (e.g., XML attribute or JSON property) on the child objects that lie inside. Dojo put a 'layoutAlign' attribute on
elements that are the children of container elements. ExtJS defines layout hierarchies in JSON where there is a parent container JavaScript object which has a list of "items" (each of which is a JavaScript object), and each item can pass layout information to its parent via JavaScript properties such as 'layout'. XAML's <DockPanel> container looks for DockPanel.Dock attributes on its child elements. (I didn't see anything like this in Spry, but I might not have been looking in the right place.

Jon: Phil, is the problem characterizied correctly?

Phil: Yep

Jon: We don't need child properties, for example, dojo align

Phil: That property may not be applicable if not in layout

Jon: Child property defined in parent then?

Phil: Yep

Jon: I agree with childProperties, 0..many properties in the widget element

Phil: That will break consistence for plurals?

Jon: Ya, maybe, that is OK, lets look at rules

Jon: Lori, question, are you going to check plurarl vs. singluar,

Lori: Since we made it optional we removed the checks

Jon: Lori, can you please read the rules to help use double check? I was going to write test cases that generate illegal test cases

All: Agreed to add childProperties element



Jon: 2008-07-21: Is 'datatype' required? I assume not. Then the question is what is the default if 'datatype' is not specified. I think the only viable default value is '*', which means any data type.

Stew: How are property editor generated?

Lori: Exactly, how do you know what you have?

Jon: Ah, got it, String it is then for the default of datatype if not supplied.

Collapsing use options into enum

Jon: Next element: 2008-07-21 Jon: right now you can have the following nested elements: <api><enums><enum><options><option>. How about collapsing <options> into <enum>, where <enum> gets the attributes that currently exist on <options>?

Jon: Take to email, Jon will write-up a proposal

menu support for properties (nesting)

Jon: Next item: 2008-07-21 Jon: Do we need nested menu support? My opinion is that we should leave it off for now until someone points out a requirement. If we need it, we can add an <optgroup> element to the language just like what HTML has.

Lori, Stew: Agree

enum tag in widge file?

Jon: Next item: 2008-04-29 Draft consensus: We approved Bertrand's proposal for an <enum> element and decided it can be a child of <api>, <widget>, and <property>. 2008-07-22 Jon: Right now the schema only shows <enum> as a child of <api>. I guess it is an oversight that it isn't a child of <widget>, but <property> already has <options>.

Jon: Pre-defined type in widget file,

Stew: Lets not put it in, we can add if it is asked for

Jon: I agree, only a child of API

file substitution in localization

Jon: Next, we have some red in localization, file substituion

From wiki: Do we have a need for parameter substitution, such as "Page {0} of {1}", where some of the localized message is passed as a parameter? This is really comon in localization systems, but not sure we need it. (Jon thinks maybe what we need is to say that localization expansion happens first, and then property expansion. That way the localization string could contain things like __pagenumber__.)

Lori: That doesn't always work, Chinese for example doesn't to that

Jon: We do not need to do that (formating as described above)

localization file naming

Jon: Next item: Do we need flexibility with regard to localization file naming? (Jon thinks we don't need it.)

Phil: We don't say anything about how to find or what the file name is?

Jon: Hard coded location? or a variable that states where to look, lets hardcode it

Phil: How are languages IDed?

Jon: You have a root directory with all localization, then you have subdirectories with locale

Jon: Lets adopt the Google naming convension, ok

All: agreed

Jon: last question: Do we need to say that all of the metadata XML files and localization files must use UTF-8 encoding? (Jon thinks that we don't need to say this. The XML files will indicate their encoding.)

All: No, XML take care of that

Phil: Do we need to add locID into every element that needs it? question to Jon

Jon: Yes
Personal tools