JSAN + prototype + scriptaculous

[Laurie Harper]

Hi, I use Scriptaculous in my application. The trouble is, it depends
on prototype and JSAN has all sorts of bits from prototype exposed in
the global context (i.e. not wrapped in a JSAN namespace or
anything). Is this going to cause problems due to incompatibilities
between the objects/functions JSAN defines, and the versions supplied
in the latest version of prototype.js?

It seems I *should* be able to load JSAN.js then prototype.js and
just let prototype.js redefine those things that are in JSAN, but if
there's anything in any JSAN distributions that depends on something
JSAN adds to an object supplied by prototype, I'm going to be
screwed... And what if I use() something that loads a JSAN module
which overwrites something defined by prototype, possibly deleting
prototype features my page (or scriptaculous) is using?

It seems to me that, unless prototype is going to be distributed as a
set of JSAN modules by default, JSAN should either have it as a
requirement and not redefine things from prototype, or define them in
a namespace that wont conflict. Am I missing something here?

Cheers,

L.
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/

[Rob Kinyon]

On 9/19/05, Laurie Harper <lau...@holoweb.net> wrote:
>
> Hi, I use Scriptaculous in my application. The trouble is, it depends
> on prototype and JSAN has all sorts of bits from prototype exposed in
> the global context (i.e. not wrapped in a JSAN namespace or
> anything). Is this going to cause problems due to incompatibilities
> between the objects/functions JSAN defines, and the versions supplied
> in the latest version of prototype.js?

Wow. It seems to be my night to reply. :-)

No, there shouldn't be any conflict between JSAN and prototype.js -
the reason is that JSAN.js doesn't use anything that I've been
converting from Prototype over into JSAN-friendly distributions.

> It seems I *should* be able to load JSAN.js then prototype.js and
> just let prototype.js redefine those things that are in JSAN, but if
> there's anything in any JSAN distributions that depends on something
> JSAN adds to an object supplied by prototype, I'm going to be
> screwed... And what if I use() something that loads a JSAN module
> which overwrites something defined by prototype, possibly deleting
> prototype features my page (or scriptaculous) is using?

Everything that I've converted from Prototype is feature-complete
vis-a-vis prototype.js. So, if it's got the same name, it "should" do
at least as much as Sam built into prototype.js. It may do more, but
it should do at least as much. If it doesn't, please provide a
testcase and I'll fix it.

> It seems to me that, unless prototype is going to be distributed as a
> set of JSAN modules by default, JSAN should either have it as a
> requirement and not redefine things from prototype, or define them in
> a namespace that wont conflict. Am I missing something here?

Sam has tentatively agreed that, once I convert prototype.js into a
complete set of modules, he'll consider repackaging prototype.js as a
wrapper around JSAN modules. (I've already started this wrapper - it's
the Prototype distribution on JSAN.)

Now, I think you're conflating two separate concepts. There's the
JSAN.js code that adds the concept of on-demand libraries to
Javascript. Then, there's the JSAN code repository. JSAN.js has no
outside dependencies on anything. (This is by design.) Various
distributions in the JSAN repository may have dependencies on other
items. For example, DOM.Element has a dependency on DOM.Utils because
it uses the $() function. As far as I'm aware, there are currently no
distributions in JSAN that depend on pieces extracted from
prototype.js, except for other pieces from prototype.js (as
demostrated above).

In short, you should be able to use Scriptaculous and prototype.js as
well as other items from the JSAN repository without any conflicts.

I hope this helps clear up any confusion.

Thanks,
Rob

[Laurie Harper]

On 20-Sep-05, at 12:33 AM, Rob Kinyon wrote:
> On 9/19/05, Laurie Harper <lau...@holoweb.net> wrote:
>> Hi, I use Scriptaculous in my application. The trouble is, it depends
>> on prototype and JSAN has all sorts of bits from prototype exposed in
>> the global context (i.e. not wrapped in a JSAN namespace or
>> anything). Is this going to cause problems due to incompatibilities
>> between the objects/functions JSAN defines, and the versions supplied
>> in the latest version of prototype.js?
>
> Wow. It seems to be my night to reply. :-)

:-)

> No, there shouldn't be any conflict between JSAN and prototype.js -
> the reason is that JSAN.js doesn't use anything that I've been
> converting from Prototype over into JSAN-friendly distributions.

Sorry, I should be careful; when I say 'JSAN' I mean 'JSAN.js or any
other package distributed through JSAN'. With things from
prototype.js available through JSAN, it's reasonable to expect that
there are or will be distributions that use them.

>> It seems I *should* be able to load JSAN.js then prototype.js and
>> just let prototype.js redefine those things that are in JSAN, but if
>> there's anything in any JSAN distributions that depends on something
>> JSAN adds to an object supplied by prototype, I'm going to be
>> screwed... And what if I use() something that loads a JSAN module
>> which overwrites something defined by prototype, possibly deleting
>> prototype features my page (or scriptaculous) is using?
>
> Everything that I've converted from Prototype is feature-complete
> vis-a-vis prototype.js. So, if it's got the same name, it "should" do
> at least as much as Sam built into prototype.js. It may do more, but
> it should do at least as much. If it doesn't, please provide a
> testcase and I'll fix it.

It's the 'may do more' part that worries me ;-) Any code written to
depend on that 'more' would break if I load a more recent
prototype.js 'over the top of' (i.e. after) JSAN or something
distributed through JSAN. Prototype is a moving target; Scriptaculous
depends on a pre-release version as it is. Are you tracking updates
to Prototype and keeping the code in JSAN in sync?

>> It seems to me that, unless prototype is going to be distributed as a
>> set of JSAN modules by default, JSAN should either have it as a
>> requirement and not redefine things from prototype, or define them in
>> a namespace that wont conflict. Am I missing something here?
>
> Sam has tentatively agreed that, once I convert prototype.js into a
> complete set of modules, he'll consider repackaging prototype.js as a
> wrapper around JSAN modules. (I've already started this wrapper - it's
> the Prototype distribution on JSAN.)

So, there's a possibility that, some time in the future, this concern
of mine might go away? I don't think I feel too comfortable building
a dependency on two things that may or may not end up aligning...
Wouldn't it make more sense to package stuff in prototype.js in its
own namespace and then, if prototype adopts JSAN, the appropriate
symbols just need to be exported from that namespace to the global
scope. If it doesn't, both can co-exist (and potentially diverge)
without conflict.

> Now, I think you're conflating two separate concepts. There's the
> JSAN.js code that adds the concept of on-demand libraries to
> Javascript. Then, there's the JSAN code repository. JSAN.js has no
> outside dependencies on anything. (This is by design.) Various
> distributions in the JSAN repository may have dependencies on other
> items. For example, DOM.Element has a dependency on DOM.Utils because
> it uses the $() function. As far as I'm aware, there are currently no
> distributions in JSAN that depend on pieces extracted from
> prototype.js, except for other pieces from prototype.js (as
> demostrated above).
>
> In short, you should be able to use Scriptaculous and prototype.js as
> well as other items from the JSAN repository without any conflicts.
>
> I hope this helps clear up any confusion.

Yes, you're right, I'm guilty of confaltion, see above ;-). Perhaps
there's a term that would cover JSAN and everything distributed
through it?

It's good to know there are no known current conflicts, but I'm still
not convinced I can rely on that remaining true in the future as long
as JSAN (in the inclusive sense) and Prototype are independently
defining the same symbols in the same scope.

I'm not trying to be difficult, I just want to be sure I understand
my risks so I can manage them effectively and make an informed choice.

[Rob Kinyon]

> It's the 'may do more' part that worries me ;-) Any code written to
> depend on that 'more' would break if I load a more recent
> prototype.js 'over the top of' (i.e. after) JSAN or something
> distributed through JSAN. Prototype is a moving target; Scriptaculous
> depends on a pre-release version as it is. Are you tracking updates
> to Prototype and keeping the code in JSAN in sync?

Currently, no. I'm converting prototype.js 1.3.1 over to JSAN. I
understand that this isn't the latest version. But, I have to start
from somewhere. The idea is to convert that over (and part of that is
adding lots and lots of tests). Then, I'll look at the diff between
whatever Sam's latest and me and apply those changes as a whole.
Hopefully, I'll get Sam to stop developing prototype.js and start
developing the JSAN'ized components instead. That way, we don't have a
fork.

> >> It seems to me that, unless prototype is going to be distributed as a
> >> set of JSAN modules by default, JSAN should either have it as a
> >> requirement and not redefine things from prototype, or define them in
> >> a namespace that wont conflict. Am I missing something here?
> >
> > Sam has tentatively agreed that, once I convert prototype.js into a
> > complete set of modules, he'll consider repackaging prototype.js as a
> > wrapper around JSAN modules. (I've already started this wrapper - it's
> > the Prototype distribution on JSAN.)
>
> So, there's a possibility that, some time in the future, this concern
> of mine might go away? I don't think I feel too comfortable building
> a dependency on two things that may or may not end up aligning...
> Wouldn't it make more sense to package stuff in prototype.js in its
> own namespace and then, if prototype adopts JSAN, the appropriate
> symbols just need to be exported from that namespace to the global
> scope. If it doesn't, both can co-exist (and potentially diverge)
> without conflict.

I'm actually doing that. Here's the thing - only a few of the
prototype.js items are in the same namespace. For example,
Ajax.Request is now HTTP.Request. The Insertions are now
DOM.Insertion, etc. Some of the items are the same, but that's the
exception, not the rule.

The Prototype distribution on JSAN is actually a compat layer, so that
code that previously used prototype.js can switch over the the
JSAN'ized version without changing their code (in theory), then
migrate at their pace.

The key is that as part of the rewrite, I also renamed. So, there
should be nearly zero conflicts. (Theoretically, of course.)

Rob

[Laurie Harper]

Great, that all sounds like things are going in the right direction
then :-) I still feel nervous about adopting JSAN in a product that
will ship relatively soon, but less so than I did... If you'd be
prepared to stipulate that any conflict I *did* find loading JSAN-
based stuff together with a non-JSAN Protoype distribution from Sam,
even better!

If I understand you correctly, I should be able to do <script
src="...JSAN.js"/> <script src="...prototype.js"/><script>JSAN.use
('whatever')</script>, and expect it to work, regardless of how
prototype changes / diverges from the 1.3.1 version you're working
from and, at some future point, replace <script src="...prototype.js"/
> with a use('Prototype').

Sounds good! :)

L.

[Rob Kinyon]

> Great, that all sounds like things are going in the right direction
> then :-) I still feel nervous about adopting JSAN in a product that
> will ship relatively soon, but less so than I did... If you'd be
> prepared to stipulate that any conflict I *did* find loading JSAN-
> based stuff together with a non-JSAN Protoype distribution from Sam,
> even better!

I'm prepared to say that I will gladly work with you to help fix any
conflicts you run into. :-)

> If I understand you correctly, I should be able to do <script
> src="...JSAN.js"/> <script src="...prototype.js"/><script>JSAN.use
> ('whatever')</script>, and expect it to work, regardless of how
> prototype changes / diverges from the 1.3.1 version you're working
> from and, at some future point, replace <script src="...prototype.js"/
> > with a use('Prototype').

Yes, that's the eventual goal. :-)

Rob

[Laurie Harper]

On 20-Sep-05, at 2:21 PM, Rob Kinyon wrote:
>> Great, that all sounds like things are going in the right direction
>> then :-) I still feel nervous about adopting JSAN in a product that
>> will ship relatively soon, but less so than I did... If you'd be
>> prepared to stipulate that any conflict I *did* find loading JSAN-
>> based stuff together with a non-JSAN Protoype distribution from Sam,
>> even better!
>
> I'm prepared to say that I will gladly work with you to help fix any
> conflicts you run into. :-)

Heh, fair enough ;-)

>> If I understand you correctly, I should be able to do <script
>> src="...JSAN.js"/> <script src="...prototype.js"/><script>JSAN.use
>> ('whatever')</script>, and expect it to work, regardless of how
>> prototype changes / diverges from the 1.3.1 version you're working
>> from and, at some future point, replace <script
>> src="...prototype.js"/
>>> with a use('Prototype').
>
> Yes, that's the eventual goal. :-)

Cool :) OK, I will certainly let you know if I run into problems.

L.