[Seaside] #script: part of the tags

[Sebastian Sastre]

Hi Lukas, 

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. 

Take the same experience but with a more tangible one: will be frustrating to
have a pen in your hand that when you say to it "pen please write hello" it do
that in the reverse of the notebook without even telling you about. Will be cool
to have a pen which responds to voice commands but will be uncool that it does
it being too much smart.

So for this case I'm saying that intuition dictates that #script in the brush
should be reserved for an immediate script tag and, as convenience, an explicit
selector (like #scriptOnLoad) to be used for the added feature of sending the
script to execute somewhere else. So that will make "the brush" to be more
intuitive.

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.

That overload of the word script (instead for instance #scriptOnLoad) which is
demanding developer costs is what I'm critizicing no matter when it was done or
by whom.

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.
Of course this won't make any good about the 'dom:loaded' vs. onLoad aspect.

Cheers,

Sebastian Sastre


> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Lukas Renggli
> Enviado el: Domingo, 07 de Septiembre de 2008 11:42
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] #script: part of the tags
> 
> >  That means that silently Seaside decided to put the script 
> part of the tag in
> >  the onLoad section which is IMHO a very poor choice this days.
> 
> This is not a silent decision of Seaside, this method had been there
> since the very beginning of the Scriptaculous package:
> 
>     Name: Scriptaculous-avi.4
>     Author: avi
>     Time: 22 September 2005, 1:59:03 pm
>     UUID: b4f48653-2bab-11da-9fc6-000a95db7844
>     Ancestors: Scriptaculous-avi.3
> 
>     Support #script: so that elements can have effects applied to them
> immediately.
> 
> >  If the idea is to mantain that silent manipulation of the 
> script tag, I
> >  recommend a review to use 'dom:loaded' instead of that 
> because it will be fired
> >  just after the html is loaded and before the images are 
> loaded and, depending on
> >  the page, that could make a lot of diference to the user 
> experience.
> 
> I think you mistake WATagBrush>>#script: for WAHtmlCanvas>>#script:.
> The two are something entirely different and both make perfect sense
> to me. Check out "Adding JavaScript" from the slides 13, 14 and 15 of
> my Seaside tutorial for a detailled explanation:
> <http://www.lukas-renggli.ch/smalltalk/seaside/tutorial/web20.pdf>.
> 
> Cheers,
> Lukas
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside