[Seaside] #script: part of the tags

Lukas Renggli renggli at gmail.com
Sun Sep 7 16:50:46 UTC 2008

>  No I'm not mistaken about them, they both do have sense to me too. The
>  difference is about overload of the term. I'm recommending them to be
>  explicitely disambiguated instead of ambiguos. If the tag is designed to allow a
>  script just below it (making aside the elegance or not of using it at all), then
>  when I talk to a brush tag and I say "script" I don't expect the *enhancement*
>  of seting the script somewhere else the same way you say to it
>  "attributeAt:put:" and you don't expect it to be set somewhere else. The object
>  is a brush to invoke the concept of you "talking" to a brush that you would
>  expect it to paint there where it is instead of somewhere else.

That's not a written rule about brushes. There are a couple examples
that don't have immediate effect on the generated XHTML. I agree that
this should be better documented though.

>  Now they are overloading the selector #script and that means the developer has
>  to 1. surprise when found this, 2 suspect about script tag not being used by the
>  brush, 3 disambiguate and learn about the unexplicitely added feature with the
>  help of navigatig code to reach an uncommented method or 4 finding slide 14 of
>  your tutorial. I don't know others, but I love magic but I do not love too much
>  magic.

I have given dozens of Scriptaculous tutorials to
Smalltalk/Seaside/JavaScript novices and this has never been a
problem. WATagBrush>>#script: does exactly what one expects in most
cases, without forcing you to know all the internal details. If this
method was called #scriptOnLoad: you would be talking about the
implementation already. Moreover it would cause a confusion between
#scriptOnLoad: and #onLoad:.

Again, the purpose of #script: is to assign a paricular script to a
tag (that's an abstraction over what you can do in plain
XHTML/JavaScript) and Seaside figures out the rest for you. I don't
even see magic here.

>  Your very appropriate comments in slide number 14 could do actually help there
>  so, at least, surprise is mitigated by saying it explicitelly instead of coded.

I've added a method comment in Scriptaculous-Core-lr.36.

>  Of course this won't make any good about the 'dom:loaded' vs. onLoad aspect.

I disagree. The purpose of #script: and #addLoadScript: is to add
scripts that evaluate when the page, all styles and images have
completed loading. The initial purpose of these methods were to play
animations or to scroll to particular places. If used with dom:loaded
(a prototype extension) these effects would be triggered too early.

dom:loaded seems to me rather pointless. In the documentation they
say: "The load event on window only fires after all page images are
loaded, making it unsuitable for some initialization purposes like
hiding page elements (so they can be shown later)." In my opinion one
should hide page elements through a style-attribute in the XHTML
already. This guarantees a flicker-less loading and you don't depend
on artificial events.

Of course nothing prevents you from contributing code that supports
the prototype dom:loaded event, if you think that this is useful.


Lukas Renggli

More information about the seaside mailing list