[Seaside] Seaside sessions and ajax

[Sebastian Sastre]

> I don't want a DIV around all my components.
> 

Thanks for the reading Lukas. I make some commments on each.

>   http://www.whatstyle.net/articles/22/less_div_more_html

Quoting it's stronger argument: 
"It's cleaner, it has less code, and therefore; less clutter and lower
maintenance."

OK, I say: that is important if you deal with that code as a direct author.
Seasiders are not direct authors of their html. Scriptaculousiders also
aren't direct authors of most javascritp they use. Seaside spits all
serialized for you so you don't have to worry about it. That fact makes that
argument extreamely weak at least for the most heavy part: lower
maintenance.
Just to illustrate: all my wrapper divs are in 1 method of this seaside
compoents family that has 16 short lines (of those, 1 is the selector of the
method, 2 are comments and 3 are separations).

>   http://www.motive.co.nz/glossary/div.php
> 
This author state he's counter divitis arguments in 3 parts:
1. complex code
I already deactivated this.

2. Quoting: "A web designer might add additional <div>s that are redundant
(in terms of the final design), but that allow for future revision to the
design. In some cases, redundant <div>s are required to account for
variations in that way that different web browsers interpret the CSS
language."

Here is being contradictive with himself by justifying why he do not make
allways what he promotes, so nothing to say.

3. Quoting: "Less-experienced webpage authors will often use a <div> in
place of a more semantically-appropriate HTML element. For example, they
might use a <div> and CSS to style text to look like a heading, rather than
using an HTML heading element (<h1>, <h2>,<h3>, etc.)."

I agree and should add that is *only* valued by webdesigners elite (which I
don't give a dime for). Not one single user will value more a heading that
looks like a header because it *is* a <h1> instead of a syled <div> nor that
will make you gain more money, so... as I stated, I don't give a dime to
HTML and or CSS beauty code. Html is conceptually poor and is doing what it
can to evolve so why I should be a devote admirer of a languange designed
bad from start? I'll, by no mean, be of the "beauty html" religion. It's not
a language for persons nor for machines. Let user agents to deal with it.

End users don't want to look your html, they should not and they ever will.
So if costs are the problem I say that technologies that spit html for you
will make that argument insignificant.

Besides they are talking mostly for pages that have extreamely simple
layouts: 1 (one) container (probably body)with 3 or 4 colums with a liquid
center. I want/need and talking about here, of having the chance of
composing ANY seaside component (of this family) trivially in an arbitrary
order of magnitude with border layout (see example:
http://extjs.com/deploy/dev/examples/layout/complex.html). I gave a quick
look in the app I'm working on and counted 9 levels deep of border layout to
reach the div that wraps a button in a medium-simple form. When I can I'll
show you some so you can firebug that insane html (firebug thank you for
exist). 

> > The fact is that didn't stop me yet of doing anything. Besides 
> > behavior, if you're valuing the elegance of the html I would agree. 
> > The html would seem heavy but todays it can travel deflated 
> by apache. 
> > Besides The structure of what I have rendered on the user agent is 
> > kind of homogeneus in nature even in a high degree of 
> composition. I 
> > know that it should be the designer's problem but I think I've also 
> > have solved a priori most of the positioning problems with this. By 
> > having a little painful experience on layouting things in 
> html you may know how valuable this could be.
> 
> I don't see how these DIVs could be valuable for a designer, 
> as they are probably auto generated. What worried me 
> initially was that I had the impression that you wanted to 
> put a DIV around every component.
> 
I may not let that clear enough. I don't want to force anything in Seaside
normal components hierarchy. Just a family of components that work like
this. Designers 99.9% probably get scared when see that html because they
are so used to manage html manually or semi-manually. But they should not.
This industrial way of using divs is meant to provide power. Power when you
use them with an associated CSS class (that by the way I also generate
automatically). The worst for webdesigners is the part they'll see
compromised CSS cascading capabilities. Several properties are repeated in
the CSS but is not that bad as it sounds. OK, my CSS is 14KB and it is
promising keep growing firmly but it goes deflated and ends cached anyway.

> > So I say we can scale
> > that to make a family of components that are also AJAXianly 
> backtrackeable.
> > Those components have the trade off of having to be identifiable in 
> > the DOM and capable of setting it's innerHTML (that's why 
> I've choosed 
> > to wrapp with div containers).
> 
> That makes sense.
> 
> > If those components have to exists in a different hierarchy 
> other than 
> > WAComponent let's be it.
> 
> Sure that's a detail. I don't see any problems in starting 
> with a subclass of WAComonent, I just feel that maybe later 
> on you might want to choose a different superclass. 
> WAComponent provides a lot of functionality that might not be 
> too useful in your context.
> 
OK, later we can review that in the name of refactoring and clean Smalltalk
code :)

> > I thought in continuations because how Seaside works. Suposing AJAX 
> > did not exists, Seaside maps one unique url per 
> reandereable action. 
> > What I was thinking is that we can map those rendereable 
> actions also 
> > to AJAX style of render elements: updaters. If the problem 
> to solve is 
> > backtrack rendereable actions, no matter if they are full 
> or partial, 
> > I think Seaside is the winner because of continuations (I say this 
> > because one can go back and forward in different "branches" 
> of actions 
> > and as far as I know only continuations handle that).
> 
> So far, I don't see any use of continuations. Seaside only 
> uses continuations to wait in the middle of a method for the 
> next request, e.g. with #call: and #answer:. The state 
> backtracking has nothing to do with continuations (with the 
> exception of the method-temps that are part of a suspended method).
> 
Now you let me thinking!.. I didn't realize that. I should take a reading on
how those methods work. Oh, I get it with the updaters we are not
interrupting any method execution in the middle right? Sure man, that is
only a need if we want to make a kind of #call: to works with AJAX. Ok, this
is the "one problem at the time baby" hour so we let that for a second
stage, I bet is solvable.

So I need to understand better how Seaside maintain things backtrakable.
What do you suggest me to read?

	Cheers,

Sebastian

> > I'm still thinking loud here so please feel free to feedback,
> 
> Interesting discussion.
> 
> 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