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

[Conrad Taylor]

On Sat, May 16, 2009 at 12:35 AM, Lukas Renggli <renggli at gmail.com> wrote:

> > 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.
>

Yes, this sounds doable to me because I really don't want to be loading
un-needing components.  Seaside provide a mechanism to automatically
generate the API when these components are included in the head tag?
For example, if a new stable release is published with a new and/or
modified API, would these new additions be added to Seaside's interface
for this component?


>
> 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.
>

I personally really don't think they would be confused anymore than someone
who's using these packages outside of Seaside 2.9.  I would even say that
the Seaside 2.9 Package Builder does an excellent job including the
associated
dependencies for a given component.

It would be great if I can click a Seaside component and select update
without
destroying the image.  At time time, I was informed that I would need to use
an
image that doesn't have Seaside in it.  It's like creating a new document
each time
you add a new paragraph to it.  Will this be resolved in the future?


> > 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?
>

Yes, I was referring to Seaside 2.9 and their 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.
>

Thanks for the information and I really appreciate it.

-Conrad


>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090516/b7ae31fe/attachment.htm