#script: part of the tags

Hi there,

Today I've found a surprising behavior (about a 'dom:loaded' event reaction
which was not executing) and debugging that lead me to the #script: method of
WATagBrush which has this code:

script: aPrototype
        aPrototype isNil
                ifTrue: [ ^ self ].
        (aPrototype respondsTo: #id:)
                ifTrue: [ aPrototype id: self ensureId ].
        aPrototype session addLoadScript: aPrototype

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.

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.

If not, I recommend two methods. One called #script: behaving as intuitively
expected for the tag and other with the "enhancement" but making it explicit
with something like #onDOMLoadedScript: so the Seaside developer can choose
instead of being (poorly) surprised.

Cheers,

Sebastian Sastre

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>  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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.
>
No is not written (that's why the controversy happens) and as you may have read,
I've suggested to decide in favor of mimic an intuitive example instead of
technical ones. In fact is not me, the word "brush" (in the class name) is
already suggesting that.
I understand that could be a convenience at first but in the end balance
changes. So novices can be surprised after some time the same as not novices do.
Clarifiying, by "magic" I mean seaside doing the abstraction for you behind the
scenes. By "too much magic" I mean deciding an implementation which is not
obvious and is counterintuitive.

I don't see #scriptOnLoad: as revealing implementation. I see it is revealing
when (not how) it will execute the script. I'm ok with hiding the implementation
but, as it makes all the difference, I'm not ok with hiding the implementation
*and* the moment.

> I've added a method comment in Scriptaculous-Core-lr.36.
>
Ok, IMHO that mitigation is a step forward.

You may not need it yet but that event, as previously said, is not only useful.
Is critical for enhancing user experience in several cases. You can make
elements do work in the DOM while images are loading. That is not poitless
unless parallelization seems pointless.

While I agree about hiding elements using css, as said, not only talking here of
visual reactions. You could easily need this event for behavior. Besides, the
event is as artificial and maintained by Prototype library as much as the
effects.

I understand about the initial intention of using it for effects but this days
you can ask for more and you can eventually need to initialize dom elements long
before onLoad happens. To illustrate this I'm using it to add dynamic behavior
and/or initialize dom state. Features I use intensively.

I imagine other libraries too. I see jQuery has an equivalent for this. They
have a function "document.ready(clousure)". By now I'm already exploiting the
prototype's 'dom:loaded' and that seems enough. I just wanted to state that also
Seaside could benefit from the feature.

Cheers,

Sebastian
PD: Code wont have much of special to achieve this. I'm using it more or less
like this:

BlahComponent>>renderContentOn: html

html div
        id: self id;
        class: #MockCSS;
        with:[self renderInnerOn: html].

html script with: (self componentScriptOn: html)

With...

BlahComponent>>componentScriptOn: html

        ^ (SUScript new
                add: ((self elementOn: html)
                        assign: (self initializeElementFunctionOn: html)
                        as: 'initializeElement');
                add: (SUEvent new
                        observe: html scriptaculous document
                        on: 'dom:loaded'
                        do: (SUFunction  new
                                argument: 'event';
                                add: ((self elementOn: html) call:
'initializeElement' argument: 'event');
                                yourself));
                yourself.

And...

BlahComponent>>elementOn: html
        "Answers the script to invoke the receiver's DOM homologous."

        ^ html element
                id: id;
                yourself

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside