This sounds like a very reasonable approach to me ....
Rich
From:
Jon Ferraiolo/Menlo Park/IBM at IBMUS
To:
ide at openajax.org
Date:
09/29/2008 07:06 AM
Subject:
[OpenAjaxIDE] Change default for 'src' attribute on <require> to be
undefined/unspecified
(IT WOULD BE GREAT IF PEOPLE RESPONDED VIA EMAIL WITHOUT TOO MUCH DELAY.
WE NEED TO KNOW WHAT TO IMPLEMENT.)
Javier is implementing some of the details around the <require> element,
which spurred a long thread of email between the two of us. Right now, if
you have:
<require type="library" name="<libname>" version="<libversion>" />
we say that the default value for 'src' is the current directory. It is
our belief that this is not a user-friendly or useful default for the very
common case where the developer is using one of the popular Ajax
libraries, most of which are huge beasts. We believe that widget
developers will generally not want to put a major Ajax library within the
root directory of each of their widgets. To break this down into two prime
scenarios:
* You are a widget developer on one of the major Ajax libraries. In this
case, the widget will be located somewhere inside the directory tree for
that library. The library's root folder will be different than the
widget's root folder.
* You are a 3rd party widget developer who is using one of the major Ajax
libraries. In this case, you probably don't want to embed a huge Ajax
library within your widget (as it will dwarf the OpenAjax-related files)
and instead want to reference the library somehow, and even if you wanted
to embed the library, it is unlikely that you would want to locate its
root folder in the same folder as the metadata file.
The immediate thing that comes to mind is that the widget developer could
use an absolute URL to point to the Ajax library somewhere on the Web, but
as Lori has pointed out previously (and as Javier has discovered when
trying to implement), this is problematic because, even if there were
reliable URLs for pulling down Ajax libraries (and I don't believe there
are reliable URLs across the industry), tools would have to implement tree
crawlers to pull down the distributions for Ajax libraries, but such tree
crawlers usually will be some combination of impossible, difficult to
implement, unreliable, fragile and slow. My conclusion is that absolute
URLs to point to Ajax libraries today provide no useful value except
possibly as a unique identifer (e.g., as the namespace URI in an XML
namespace declaration) or as a reference (e.g., point to the toolkit's
home page), but is unworkable for pulling down library distributions.
Furthermore, even if absolute URLs could be made to work, how would widget
developers figure out what absolute URL to use for which toolkit (in fact,
a particular version of a particular toolkit)? Would OpenAjax publish a
list of absolute URLs for major toolkits, perhaps as part of our Registry?
I am afraid of trying to leverage the Registry for lots of reasons,
including that we don't have it set up as a web service at this point.
In my opinion, to provide the most useful technology to the industry, the
best option (or perhaps the least worst option) would be to do the
following:
* Hard code into the spec a short list of popular client-side (i.e.,
JavaScript-only) Ajax libraries, listing a standard prefix and the home
page for the toolkit
* If the metadata includes <require type="library" name="<libname>"
version="<libversion>" />, and does not specify 'src', and <libname> is
one of the major libraries listed in the spec, then tools are expected to
have that library available somehow, either by including the library
within the product itself or by dynamically pulling it down from the Web
on an as-needed basis
Regarding which toolkits make the list, and which ones don't, I propose
that we use the list of libraries shown at
http://code.google.com/apis/ajaxlibs/, which is the list of major
libraries that Google felt were most important to support with their Ajax
library loader project. Their list: jQuery, jQueryUI, prototype,
scriptaculous, mootools, dojo. The W3C adopted a similar approach with
font formats where they hardcoded a particular list:
http://www.w3.org/TR/CSS2/fonts.html#referencing, with the ability to use
other font formats as you need (e.g., Adobe SVG Viewer used a format
called CEF) . Also, browsers hardcode particular image types (e.g., JPEG,
PNG, GIF) but the list of image types is extensible.
This approach will make life easy on the 80%/90% of widget developers who
use one of the most popular Ajax libraries because they don't have to
specify 'src' at all. For example, widgets that use Dojo can simply say:
<require type="library" name="dojo" version="1.1"/>
<require type="javascript" library="dojo" src="dojo/dojo.js"/> <!-- This
line puts a SCRIPT tag in the HEAD -->
For widgets that use other libraries, we would recommend that widget
developer to include the library within their widget and reference via a
relative URL on the 'src' attribute.
Comments?
Jon_______________________________________________
IDE mailing list
IDE at openajax.orghttp://openajax.org/mailman/listinfo/ide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080929/977e1757/attachment-0001.html