Updated OpenJSAN Loader

[jhuni]

http://github.com/openjsan/just/issues#issue/1

This issue requests that the loader is changed to Just instead of
JSAN, and I think I have accomplished that here:

http://github.com/jhuni/just/blob/master/lib/JSAN.js

What I have done is I have made the entire class definition wrapped in
a anonymous subroutine so you can easily change the name of the loader
to whatever you want:

WhateverYouWant = (function () { /* Class is here */ })()

http://github.com/openjsan/just/issues#issue/3

I think that done that with jsan.observers which allows you to plug-in
things to respond to whenever a file is loaded, and you can replace
the slurp function with something else for different platforms.

http://github.com/jhuni/just/blob/master/lib/JSAN.js

I think this is the most important development. The loader is now
completely independent of the Exporter, so the loader can just focus
on efficiently loading files and the Exporter set of modules can deal
with exporting things into the global name-space. I think I will
probably eventually remove the Exporter modules completely out of the
loader's repository.

http://github.com/jhuni/just/blob/master/lib/Exporter.js

There is the Exporter file, it uses jsan.observers so that when the
exporter is around the JSAN interface will work basically the same as
it did before, that is when you type JSAN.use it will do as you
expect.

http://github.com/jhuni/just/blob/master/lib/Joose/Namespace/Exporter.js

I have also built an Exporter file built upon Joose, and I may build
more Exporter modules in the future, which handle exporting data in
the form of EXPORT, EXPORT_OK, and EXPORT_TAGS.

http://search.cpan.org/~anno/Exporter-Renaming-1.18/Renaming.pm

For example, I am thinking about building something like that module
which allows you to rename things on export, and it would be nice to
allow you to rename symbols to coincide with this library:

http://cross-browser.com/x/lib/view.php?s=xlibrary

That way if you have the plan function from Test.Simple it will turn
into xPlan, which might be a useful feature for some peoples.

[jhuni]

I mean to link to this issue rather then linking to JSAN.js twice:

Remove Exporter from JSAN: http://github.com/openjsan/just/issues#issue/2

[David E. Wheeler]

On Apr 5, 2010, at 2:31 AM, jhuni wrote:

> http://github.com/openjsan/just/issues#issue/1
>
> This issue requests that the loader is changed to Just instead of
> JSAN, and I think I have accomplished that here:
>
> http://github.com/jhuni/just/blob/master/lib/JSAN.js
>
> What I have done is I have made the entire class definition wrapped in
> a anonymous subroutine so you can easily change the name of the loader
> to whatever you want:
>
> WhateverYouWant = (function () { /* Class is here */ })()

Very nice. What's the default when you just load it?

> http://github.com/openjsan/just/issues#issue/3
>
> I think that done that with jsan.observers which allows you to plug-in
> things to respond to whenever a file is loaded, and you can replace
> the slurp function with something else for different platforms.
>
> http://github.com/jhuni/just/blob/master/lib/JSAN.js
>
> I think this is the most important development. The loader is now
> completely independent of the Exporter, so the loader can just focus
> on efficiently loading files and the Exporter set of modules can deal
> with exporting things into the global name-space. I think I will
> probably eventually remove the Exporter modules completely out of the
> loader's repository.

Excellent.

> http://github.com/jhuni/just/blob/master/lib/Exporter.js
>
> There is the Exporter file, it uses jsan.observers so that when the
> exporter is around the JSAN interface will work basically the same as
> it did before, that is when you type JSAN.use it will do as you
> expect.

Nice.

> http://github.com/jhuni/just/blob/master/lib/Joose/Namespace/Exporter.js
>
> I have also built an Exporter file built upon Joose, and I may build
> more Exporter modules in the future, which handle exporting data in
> the form of EXPORT, EXPORT_OK, and EXPORT_TAGS.

Okay, sure.

> http://search.cpan.org/~anno/Exporter-Renaming-1.18/Renaming.pm
>
> For example, I am thinking about building something like that module
> which allows you to rename things on export, and it would be nice to
> allow you to rename symbols to coincide with this library:
>
> http://cross-browser.com/x/lib/view.php?s=xlibrary
>
> That way if you have the plan function from Test.Simple it will turn
> into xPlan, which might be a useful feature for some peoples.

I like Sub::Exporter, myself.

http://search.cpan.org/perldoc?Sub::Exporter

So, do you have commit access to openjsan/just on GitHub?

Best,

David

[jhuni]

Currently the openjsan loader runs very well on the local-host, like
if you have your own installation of apache and your just using it to
play around with JavaScript, however, it doesn't work that well if it
is requesting its data from a server, as such I think I have a
relatively good solution for that.

Since basically everyone stores their JSAN dependencies on the top of
their files anyway, just put two comments around your dependencies
handling statements, then if you are executing the code locally where
optimizations don't matter the comments don't mean a thing, but then
if you are requesting the data from a server it can process them and
output highly optimized and combined JavaScript code:

http://gist.github.com/360014

That gist shows what I mean. The loader can send all of the files that
it previously loaded over $_POST, that way the server won't
accidentally include a file that is already there. Then if there is
recursive dependencies, that is if one of the files has a header as
well, just process that file before including it into the requested
file, what do you think?

Another thing about this, is that all of our openjsan components
should be split up into tiny tiny pieces, that way you can just
include the things you want in your dependencies header. Like you can
include just the functions you want, rather then include a module of
functions, five of which you wouldn't be using.