[Seaside-dev] Prototype and script.aculo.us frameworks in Seaside 2.9

[Lukas Renggli]

> Hi, I was wondering, what was the rationale for creating a single package
> for Prototype and script.aculo.us.

Yeah, that bothered me a bit as well. The combination has historical reasons.

> Most times I tend to use Prototype without script.aculo.us.  I'm asking
> this question because I'm concerned
> about loading stuff that I will not use in production (i.e. lean
> deployment environment).

In practice this is no big deal though. If you just use the prototype
functionality there is no problem just to include prototype.js with
your deployed application.

A possible way of doing this is by including
"http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js"
into the HTML HEAD, instead of adding the file library that contains
Prototype and script.aculo.us.

Now that we have a common infrastructure for Javascript support in
Seaside 2.9 it would probably make sense to split the Scriptaculous
package. There is also a jQuery and jQuery-UI package that can be
loaded separately and that play a similar role as  Prototype and
script.aculo.us.

The only concern I have about splitting the Scriptaculous package is
that people will be confused and that code needs to be migrated. If
anybody has an idea of a clean way of doing this, please let me know.

> Next, I'm curious about the naming of the test for their associated
> components.  Thus, is it a convention to
> name the tests "<component-name-prefix>-Tests-<component-name-suffix>?  Did
> the development team
> consider the following:
> <component-name>-Tests

<component-name-prefix> is the poor-mens namespace, that we require to
avoid name conflicts until all Smalltalk's support some sort of a
compatible namespace implementation.

Mhh, now I am confused. Are you referring to Seaside 2.8 or Seaside
2.9? Are you referring to class names or package names?

If you refer to package naming in Seaside 2.9 the conventions are
given here: <http://code.google.com/p/seaside/wiki/PackageNaming>.
Sticking to exactly that  scheme is important in Pharo and Squeak,
because packages are defined using category prefixes.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch