[OpenAjaxIDE] <required>: type=library|folder

Jon Ferraiolo jferrai at us.ibm.com
Fri Jul 18 17:22:23 PDT 2008

Hi Lori,
See inline below.

Lori Hylan-Cho <lorihc at adobe.com> wrote on 07/18/2008 02:33:40 PM:

> Hi Jon
> Thanks for following up on this (my other message about renewing this
> discussion apparently crossed yours). I think the two outstanding issues
> me are #2 and #3 from my second e-mail, namely:
> 2. How will the IDE know the type of the file(s) being referenced with
> type="library"?
>   a. Is the assumption that "library" implies JS?
>   b. What of css files that might be included in a library distribution?
>   c. Is there an expectation that IDEs will attempt to determine the file
> type from the file extension?

I have been thinking that 'library' means folder which is copied into the
deployment area. The entire folder would be copied (JS, CSS, images, readme
files, whatever).

For example, let's look at Dojo. In typical practice, here is what I was
thinking you would say:

<require type="library" name="dojo" version="1.1.2"
src="...path-to-dojo-root-dir..." target="..."/>
<require type="javascript" src="...path-to-dojo-root-dir.../dojo/dojo.js"

That's what I was thinking at least. The first <require> would result in
the Dojo distribution getting copied. Because there is a 'name' and
'version' attribute, there would be an opportunity for sharing that
distribution across multiple widgets. The second <require> statement would
result in the placement of a SCRIPT element in the HEAD of the document.

The one implication of the previous paragraph is that the dojo.js file
would get copied twice according to my proposed rules. Obviously that isn't
optimal. There are a few things we can do. For example, perhaps the file
could look like this instead:

<require type="library" library="dojo" version="1.1.2"
src="...path-to-dojo-root-dir..." target="..."/>
<require type="javascript" library="dojo" version="1.1.2"
src="...path-to-dojo-root-dir.../dojo/dojo.js" target="..."/>

which provides sufficient information to the tool that it can figure out
that dojo.js doesn't need to be copied because it is part of a library that
has already been copied.

Also, I'm not sure if we have figured out everything with the 'target'

> 3. Is it possible for a widget developer to specify an absolute URL for
> type="library" or type="folder"?
>   a. Would the IDE then be responsible for either crawling that folder or
> downloading it?
>   b. See #2.

Crawling through a Web site seems like quite a bit to ask, but here are 3
ways we could go:

1) Require library support for crawling. Put the burden on library
developers to post their libraries in a "crawlable" manner. (Although I'm
not sure what the best approach for that. I could guess they would need to
include a manifest file that lists all of the files in their distribution,
such as the result of the UNIX 'find' comment.)
2) Require a ZIP version. Put the burden on library developers to post a
ZIP version of their distribution.
3) Don't support absolute URLs.

My favorite is #1, but this isn't clearcut. If we go for #1, then the
question is what format to use. Atom? (

> On 7/18/08 11:51 AM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:
> > One of the open topics from this week's phone call was a response to
> > email (http://openajax.org/pipermail/ide/2008q3/000539.html):
> > ----
> > ...
> > 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
> > 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
> > another file of the same name.
> > ----
> >
> > I studied a few major toolkits and thought things over. One observation
> > that it appears that major Ajax libraries support a workflow where you
> > their entire Ajax library onto your Web site, which potentially wastes
> > space on the server, but they all have modularization techniques such
> > 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 tagsfor
> > modules. For Dojo, there are multiple advanced options due to their
> > system, but the "normal" way of using Dojo is to include a script tag
> > "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 believethe
> > approach for Prototype and jQuery, which are relatively small, is to
> > 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,
> > that indicates that an asset is subject to sharing.
> >
> > 2) As Lori suggests above, if type="library", then a properly
> > metadata file SHOULD include a 'name' and a version attribute so that
> > 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
> > '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
> > 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
> > that are compatible with this widget, or do we need to specify what
> > version number is for the library that is referenced by the 'src'
> > or both? There are usually too many dependencies between widgets
> and libraries
> > such that a particular widget will often only work with only one
> > version of a library, or (for widgets defined by a 3rd party on top of
> > particular library) a particular generation of a library (e.g., Dojo
> > 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
> > 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,
> > 'name' attribute for a library should refer to a registered name with
> > OpenAjax Registry.
> >
> > 6) We need to have a well-defined processing model if attributes
> > 'version' or 'compatibility' is missing. One option is to treat asan
> > but error situations are usually messy, and usually better to figure
> > 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
> > 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
> > keywords because of the semantic value of the word 'library', but
> > 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
> > 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
> > library.
> >
> > 8) I think it makes sense for 'name', 'version' and 'compatibility' to
> > work with the other types (e.g., type='javascript') so that a tool can
> > 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
> >
> >
> > _______________________________________________
> > IDE mailing list
> > IDE at openajax.org
> > http://openajax.org/mailman/listinfo/ide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080718/f99a6da4/attachment.html 

More information about the IDE mailing list