JSAN modules installation
Nickolay Platonov
This is a separate thread, dedicated to JSAN modules installation.
The goal is to add a decent 'install' action to Module::Build::JSAN, which will install the distribution locally, somewhere in the system.
There is some initial progress:
http://github.com/SamuraiJack/module-build-jsan/tree/master
(details in http://groups.google.com/group/jsan/browse_thread/thread/a12676cd599b7dbd)
Current question I'd like to discuss here is - how to handle *.css files and images?
Any JS project starting from a certain point of complexity includes them. And they certainly should be installed
somewhere, like *.js files, and organized.
Should it be a separate /css and /img directories (alongside with /lib)?
Or will be better to put them in /lib under separate namespace, like
/lib/My/Distribution/Name/img/image1.png
/lib/My/Distribution/Name/css/full.css
?
RFC
Regards, Nickolay
David E. Wheeler
> This is a separate thread, dedicated to JSAN modules installation.
> The goal is to add a decent 'install' action to Module::Build::JSAN,
> which will install the distribution locally, somewhere in the system.
Just to clarify, Module::Build::JSAN is a Perl module that builds JSAN
distributions. It does not currently include the Build.PL script in
the distribution, however; I had assumed that most folks downloading
from OpenJSAN would not be Perl folks, but JavaScript folks, and that
they'd copy the sources to wherever they wanted them.
Nickolay has suggested to me that we go ahead and include Build.PL,
and determine some sort of global location to *install* the JavaScript
libraries. This would allow users to do something like this:
perl Build.PL
./Build
./Build install
If they wanted to change the default location, (whatever it might be),
the could do this:
./Build install --install_base ~/Sites/whatever
Of course, anyone not wanting to use Perl could just ignore the
Build.PL script. But assuming they want the script, there are two
questions that need answering. The first is: What should be the
default location for installing JSAN libraries? Perhaps in a "jsan"
subdirectory of the first directory in `$Config{libspath}`?
> There is some initial progress:
> http://github.com/SamuraiJack/module-build-jsan/tree/master
> (details in http://groups.google.com/group/jsan/browse_thread/thread/a12676cd599b7dbd)
>
> Current question I'd like to discuss here is - how to handle *.css
> files and images?
>
> Any JS project starting from a certain point of complexity includes
> them. And they certainly should be installed
> somewhere, like *.js files, and organized.
>
> Should it be a separate /css and /img directories (alongside with /
> lib)?
>
> Or will be better to put them in /lib under separate namespace, like
> /lib/My/Distribution/Name/img/image1.png
> /lib/My/Distribution/Name/css/full.css
This is the second question. I usually put such extra files in an etc/
directory in my Perl distribution, but perhaps it makes sense to have
img and css top-level directories for JavaScript libraries?
Best,
David
Nickolay Platonov
Jeremy Wall
David E. Wheeler
> I vote for ext/ or static/ toplevel directory. with css and image
> subdirectories. It seems cleaner to me and less cluttered.
> Additionally any non css or image directories could be placed there
> as well. static xml or json files for instance. I work on a project
> that makes heavy use of static json and xml files and is entirely
> javascript with no server side component. I'm sure other projects
> will have similar needs. It makes sense to provide a standardized
> location to put directories with those in.
I *think* that this is what etc/ is used for in a traditional Unix-
style tarball, no?
Best,
David
Nickolay Platonov
/ext sounds like "external" - for me, it mean - external non-JSAN distribution
Another related question here is - where it (css&images) will be installed?
Current library directory structure is as follows:
/bin
/lib
/lib/javascript
/lib/javascript/.arch
/lib/javascript/.arch/auto
/lib/javascript/.arch/auto/Test.Run
/lib/javascript/Test/Run.js
So, at the installation side
/static/My/Distribution/Name/whatever.jpg
/static/My/Distribution/Name/whatever.css
?
P.S. Can we get rid from .arch directory (which is an "arch" installation directory in Module::Build)
or it is required for some reason, which I dont know?
P.P.S Anyone knew about current practice with XS components? CSS and images resemble them very much.
Regards, Nickolay
David E. Wheeler
> /static in distribution sounds good
>
> /ext sounds like "external" - for me, it mean - external non-JSAN
> distribution
Yeah, I agree with that. I like /etc, personally, but overall don't
really care.
> Another related question here is - where it (css&images) will be
> installed?
Shouldn't we first settle where the JavaScript libraries should be
installed? FWIW, etc/ files in CPAN modules are not installed, AFAIK.
> P.S. Can we get rid from .arch directory (which is an "arch"
> installation directory in Module::Build)
> or it is required for some reason, which I dont know?
It's for compiled modules; we don't need it for JavaScript.
> P.P.S Anyone knew about current practice with XS components? CSS and
> images resemble them very much.
AFAIK, they're just kept in the lib tree with the .pm files.
Best,
David
Nickolay Platonov
Yeah, I agree with that. I like /etc, personally, but overall don't
On Apr 28, 2009, at 1:48 AM, Nickolay Platonov wrote:
> /static in distribution sounds good
>
> /ext sounds like "external" - for me, it mean - external non-JSAN
> distribution
really care.
Shouldn't we first settle where the JavaScript libraries should be
> Another related question here is - where it (css&images) will be
> installed?
installed?
Well, how about the installation targets to be determined in this order
--install-base command-line switch
$ENV{JSLIB}
and "jsan" subdirectory of the first directory in `$Config{libspath}`
?
As I understand it will be somewhere in the /usr/local/lib ?
FWIW, etc/ files in CPAN modules are not installed, AFAIK.
css and images are often referenced from run-time (during DOM creation) - we need to have fixed links to them.
Regards, Nickolay
David E. Wheeler
> Well, how about the installation targets to be determined in this
> order
> --install-base command-line switch
> $ENV{JSLIB}
> and "jsan" subdirectory of the first directory in `$Config{libspath}`
> ?
Perfect. Unless the environment variable should be JSANLIB? Either
works for me.
> As I understand it will be somewhere in the /usr/local/lib ?
Yeah, or /usr/lib, or /Library. Depends on the OS, but seems pretty
reasonable to me.
> css and images are often referenced from run-time (during DOM
> creation) - we
> need to have fixed links to them.
I agree that they should be installed.
Best,
David
Nickolay Platonov
Nickolay Platonov
It can be tried from here
http://github.com/SamuraiJack/module-build-jsan/tree/master
I suggest to return to the /static question
How about this approach (I'll demonstare on example)
Distribution side:
/lib
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/static
/static/My/Dist/Name.css
/static/My/Dist/Name/SubName1.jpg
/static/My/Dist/Name/SubName2.png
/static/My/Dist/Name/SubName3.css
...
Installation side - generally the same:
/lib
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/static
/static/My/Dist/Name.css
/static/My/Dist/Name/SubName1.jpg
/static/My/Dist/Name/SubName2.png
/static/My/Dist/Name/SubName3.css
Except distribution name prefix there is no other restrictions on file names for css & images
Cees Hek
> Well, M::B::J modified. I also removed installation of "arch" file tree.
>
> It can be tried from here
> http://github.com/SamuraiJack/module-build-jsan/tree/master
>
> I suggest to return to the /static question
Hey All,
Jumping in to give my 2 cents. Glad to see this project geting revived.
I'm not sure if 'static' sounds right to me. After all the js files
are static as well... In the unix world, these files are often put in
the 'share' directory which is for architecture independent files (and
really, the js files fit this description as well).
Looking at it from a different angle, designers and JS developers
sometimes use a directory called 'assets' for support files like css
and images (and js files for that matter).
As for installation location, this doesn't directly apply, but with
Apache2::UploadProgress (a mod_perl module) we needed to install css
and images along with the perl modulel, and we wanted them to be
automatically discoverable from the web server. To do this we
installed them along side the perl module so everything was in the
same location (if the pm file went in
/usr/local/lib/perl/Apache2/UploadProgress.pm, then the assets went in
/usr/local/lib/perl/Apache2/UploadProgress/ ). And since
Apache2::UploadProgress is a mod_perl module, can automatically set up
an Alias directive pointing to the location of the asset files:
if ( Apache2::ServerUtil::restart_count() > 1
&& Apache2::Module::loaded('mod_alias.c')
&& Apache2::Module::loaded('mod_mime.c') ) {
my $config = [
sprintf( 'Alias /UploadProgress %s/extra', substr(
__FILE__, 0, -3 ) ),
'<Location /UploadProgress>',
'SetHandler default-handler',
Apache2::Module::loaded('mod_expires.c')
? ( 'ExpiresActive On', 'ExpiresDefault "access plus 1 day"')
: (),
'</Location>',
'<Location /UpdateProgress>',
'SetHandler modperl',
'PerlResponseHandler Apache2::UploadProgress->progress',
'</Location>'
];
Apache2::ServerUtil->server->add_config($config);
}
This sets up the Alias directive which uses __FILE__ which in the perl
world points to the path to the current file. It also sets up some
expiry headers to limit requests for these files to once a day, and
then lastly sets up the upload progress handler. This is zero
configuration for the user, just load Apache2::UploadProgress in your
apache configuration and everything else is done for you.
If we are installing css and image files, then we could easily come up
with Apache2::JSAN to do auto discovery of the locations and setup
Aliases accordingly (obviously other modules could be provided as well
in different languages so as not to require mod_perl for this).
Coming back to the original question surrounding the 'static'
directory, in Apache2::UploadProgress we called this directory
'extra'.
Cheers,
Cees
David E. Wheeler
> Well, M::B::J modified. I also removed installation of "arch" file
> tree.
>
> It can be tried from here
> http://github.com/SamuraiJack/module-build-jsan/tree/master
I'll check it out.
> I suggest to return to the /static question
>
> How about this approach (I'll demonstare on example)
>
> Distribution side:
> /lib
> /lib/My/Dist/Name.js
> /lib/My/Dist/Name/SubName.js
Fine.
> /static
> /static/My/Dist/Name.css
> /static/My/Dist/Name/SubName1.jpg
> /static/My/Dist/Name/SubName2.png
> /static/My/Dist/Name/SubName3.css
> ...
I would never name those files for JavaScript classes. It should just
be:
/static/
/static/css/somefile.css
/static/img/somefile.png
/static/img/someelse.jpg
> Installation side - generally the same:
> /lib
> /lib/My/Dist/Name.js
> /lib/My/Dist/Name/SubName.js
Right.
> /static
> /static/My/Dist/Name.css
> /static/My/Dist/Name/SubName1.jpg
> /static/My/Dist/Name/SubName2.png
> /static/My/Dist/Name/SubName3.css
Bleh.
> Except distribution name prefix there is no other restrictions on
> file names for css & images
I guess you'd need to install the static files in directories named
for the JS libraries so as to avoid conflicts with static files in
other libraries, but…ugh.
Best,
David
Dan Brook
> Well, M::B::J modified. I also removed installation of "arch" file tree.
>
> It can be tried from here
> http://github.com/SamuraiJack/module-build-jsan/tree/master
>
> I suggest to return to the /static question
>
> How about this approach (I'll demonstare on example)
>
> Distribution side:
> /lib
> /lib/My/Dist/Name.js
> /lib/My/Dist/Name/SubName.js
>
> /static
> /static/My/Dist/Name.css
> /static/My/Dist/Name/SubName1.jpg
> /static/My/Dist/Name/SubName2.png
> /static/My/Dist/Name/SubName3.css
I'd like to suggest either /assets or /resources for any non-JS files.
The former being a YUI standard the latter being a MS standard (IIRC).
Either way I don't think /static is the right label for such files.
Cheers,
Dan B
David E. Wheeler
>> /static
>> /static/My/Dist/Name.css
>> /static/My/Dist/Name/SubName1.jpg
>> /static/My/Dist/Name/SubName2.png
>> /static/My/Dist/Name/SubName3.css
>
> I'd like to suggest either /assets or /resources for any non-JS files.
> The former being a YUI standard the latter being a MS standard (IIRC).
> Either way I don't think /static is the right label for such files.
Okay, it's clear to me that we should settle on something as a
default, with recommendations for organizing things, but give people
the ability to change it if they want via a parameter in Build.PL.
Best,
David
zaphar
On Apr 29, 11:01 am, "David E. Wheeler" <da...@justatheory.com> wrote:
> On Apr 29, 2009, at 2:01 AM, Dan Brook wrote:
>
> >> /static
> >> /static/My/Dist/Name.css
> >> /static/My/Dist/Name/SubName1.jpg
> >> /static/My/Dist/Name/SubName2.png
> >> /static/My/Dist/Name/SubName3.css
>
> > I'd like to suggest either /assets or /resources for any non-JS files.
> > The former being a YUI standard the latter being a MS standard (IIRC).
> > Either way I don't think /static is the right label for such files.
consider my vote switched.
The MS standard if I recall correctly was actually /res nor /
resources.
Nickolay Platonov
It comes from Catalyst..
Catalyst uses this approach:
On distribution side:
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/root
/root/static/Subname1.jpg
/root/static/Subname2.css
On installation side (blib):
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/lib/My/Dist/Name/root
/lib/My/Dist/Name/root/static/Subname1.jpg
/lib/My/Dist/Name/root/static/Subname2.css
The advantage of this approach is, that if you want to maintain a several @INC paths, you don't need to separately
maintain @INC paths for source files and @INC paths for static files.
In the previously suggested scheme, when /static were placed in separate installation tree, a secondary @INC - @STATIC_INC
were needed.
+1 for assets I like that name very appropriate I think.
consider my vote switched.
> Okay, it's clear to me that we should settle on something as a
> default, with recommendations for organizing things, but give people
> the ability to change it if they want via a parameter in Build.PL.
Agree - configuration parameter is required.
Regards, Nickolay
David E. Wheeler
> While playing with JSAN::Prove, Test.Run, Task.ExtJS and friends I
> pickup'ed a fresh idea about /static directory.
>
> It comes from Catalyst..
>
> Catalyst uses this approach:
>
> On distribution side:
>
> /lib/My/Dist/Name.js
> /lib/My/Dist/Name/SubName.js
>
> /root
> /root/static/Subname1.jpg
> /root/static/Subname2.css
>
> On installation side (blib):
>
> /lib/My/Dist/Name.js
> /lib/My/Dist/Name/SubName.js
>
> /lib/My/Dist/Name/root
> /lib/My/Dist/Name/root/static/Subname1.jpg
> /lib/My/Dist/Name/root/static/Subname2.css
Well, right now, if you organize your module like so:
lib/My/Dist/Name.js
lib/My/Dist/SubName.js
lib/My/Dist/Name/root/static/Subname1.jpg
lib/My/Dist/Name/root/static/Subname2.css
Then all you have to do to get the above structure is add these lines
to your Build.PL:
$build->add_build_element('jpg');
$build->add_build_element('css');
That's it, Module::Build handles the rest for you.
Best,
David
Nickolay Platonov
Well, right now, if you organize your module like so:
lib/My/Dist/SubName.js
lib/My/Dist/Name.js
lib/My/Dist/Name/root/static/Subname1.jpgThen all you have to do to get the above structure is add these lines
lib/My/Dist/Name/root/static/Subname2.css
to your Build.PL:
$build->add_build_element('jpg');
$build->add_build_element('css');
- /root (or /static, /assets etc) is hidden somewhere in the /lib
- Only 'jpg' and 'css' files will be installed. Files with exotic extensions will be skipped.
Probably the whole /root directory with all its content should be copied.
Current implementation also suffer from 2nd point.
Well, will we follow the approach of Catalyst?
Regards, Nickolay
David E. Wheeler
> Here will be 2 disadvantages
> - /root (or /static, /assets etc) is hidden somewhere in the /lib
*shrug*
> - Only 'jpg' and 'css' files will be installed. Files with exotic
> extensions
> will be skipped.
No, just add them all via calls to `add_build_element()`.
> Probably the whole /root directory with all its content should be
> copied.
>
> Current implementation also suffer from 2nd point.
Huh?
Best,
David
Nickolay Platonov
Nickolay
Nickolay Platonov
http://jjnapiorkowski.vox.com/library/post/rfc-non-code-data-directories-and-standards-for-catalyst.html
On distribution side:
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/static/css/Subname2.css
On installation side:
/lib/My/Dist/Name.js
/lib/My/Dist/Name/SubName.js
/static/My-Dist-Name/css/Subname2.css
I'm encouraging community members to provide any feedback, this issue is a current blocker for the whole process.
Regards, Nickolay