[Seaside] #script: part of the tags

[Sebastian Sastre]

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

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

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