[OpenAjaxIDE] more on <require>

Jon Ferraiolo jferrai at us.ibm.com
Wed Jul 30 13:23:00 PDT 2008

See inline below.

ide-bounces at openajax.org wrote on 07/30/2008 12:22:42 PM:

> hi all
> Kin and I have been writing up some usage scenarios around <required>
> files, and we've come up with a couple questions that need clarifying.
> 1. I noticed that most dojo widget examples @import their stylesheets.
> We have provisions for <link> and raw style declarations, but nothing
> for @import.
>    - I'd originally thought, "oh well, I'll just put them as the content
> of a <require type="css"> tag, which will add them in a style block,"
> but the paths then become problematic.
>    - Is there any reason those @imports can't be <link>s??

Regarding @import: I searched for @import in the dijit/ directory of dojo
1.1.1. It looks like @import only appears in:

=> .css files, which should be OK because the @import rule works relative
to the CSS file that contains the @import instruction. Therefore, if the
result HTML page can find the referencing CSS file, the @import will work

=> demo and test HTML files, which are samples HTML applications that use
Dojo but are independent of the various widgets

Is my analysis correct? If so, then maybe there isn't a problem.

> 2. Both Kin and I think it's a little weird to specify a minVersion for
> a library when the src is obviously a specific version. What are we
> trying to convey with this attribute, that the IDE doesn't need to copy
> the contents of the library folder if the user already has the
> minVersion of the same library in his site?
>     - Do we not also need a version attribute for all require types
> indicating what version the supplied file *is*?

Regarding minVersion, that attribute is part of the pair of attributes
which is 'name' and 'minVersion' for <require type="library" name="dojo"
minVersion="1.0"> and is 'library', 'minVersion' for the other <require>
constructions (e.g., <require type="javascript" library="dojo"
minVersion="1.0"). The idea is that different widgets might reference a
shared library from folders with different names (e.g.,
"dojo-release-1.1.1" versus just plain "dojo") and different widgets might
use slightly different versions of the same library (e.g.,
"dojo-release-1.1.1" versus "dojo-release-1.1.2"). The library's unique
name (e.g., "dojo", unique due to OpenAjax Registry) and its minimum
version (e.g., "1.1.1" and "1.1.2") would tell the IDE that  two widgets
could shared dojo 1.1.2.

But your comment about minVersion vs actual version is interesting. Maybe
we need two attributes, 'minVersion' and 'srcVersion', where 'minVersion'
tells the IDE that this widget can work with (e.g.,) dojo 1.1 or greater,
and 'srcVersion' tells the IDE exactly which version the 'src' attribute is
pointing to.

> 3. Should we specify that any libraries must be listed before any
> individual files that might be part of that library?

Regarding whether <require type="library"> having to appear before any
other <require> elements that use the library, I would like to hear from
implementers what they think. My guess is that implementers will tend to
parse the whole file at once (versus streaming the file) and therefore when
searching for elements that match <require type="library">, it is easier to
just look at the parsed DOM for all <require type="library"> elements no
matter whether they appear before or after the other <require> elements
that use the library.

> 4. Is it possible to reference a library in an individual file <require>
> if that library hasn't also been specified? That is:
> <require type="javascript" library="yui" src="foo/bar/yui-events.js" />
> I was thinking yes, because it'd be a way for the developer to say, "you
> don't really need *all* the files in the library, just the ones I'm
> specifying here -- but they should still be saved in the folder for that
> library, because other widgets might depend on them as well.

Do we really need to support this? The processing rules for <require> are
complex already for developers (both widget developers and IDE developers).
But if we really need this, OK with me. If we add this, then we need to be
very clear about the processing model, such as which combination of
attributes (and circumstances) cause files to be copied. For the case
above, the rules would be as follows: If there is a 'library' attribute,
then the IDE looks to see if there is a <require type="library"> element
that matches the given library name and necessary versions; if so, then the
library files will already have been copied, so no need to copy this
particular asset. Else (i.e., there is not a <require type="library">
element that matches), then copy this asset on an individual basis.

> However,
> Kin brought up a good point: Since we decided that src is relative to
> the library folder (and I think that was the right decision), what
> happens when there's no library folder? I'm thinking that a folder with
> the library name (and perhaps the version, if supplied) should be
> created wherever the IDE stores libraries, and the files should go in
> there. Should we even define this behavior for IDEs, or let them figure
> out what they want to do in the absence of a specified library folder?

It seems to me that an IDE can create library folders with whatever names
they want, given that all of the references to particular assets within the
library are relative to that root folder.

> cheers,
> Lori
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Lori Hylan-Cho
> Computer Scientist, Dreamweaver
> Adobe Systems, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080730/2a5cda89/attachment.html 

More information about the IDE mailing list