[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.
Jon


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
for
> 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"
target="..."/>

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'
attribute.

>
> 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? (
http://en.wikipedia.org/wiki/Atom_(standard))


>
>
> 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
Lori's
> > 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
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 tagsfor
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 believethe
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 asan
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
> >
> >
> > _______________________________________________
> > 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