<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Seaside] Seaside sessions and ajax</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT size=2><FONT
color=#0000ff><SPAN class=453301016-06122007>Hi
Boris,</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT size=2><FONT
color=#0000ff><SPAN
class=453301016-06122007></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT size=2><FONT
color=#0000ff><SPAN class=453301016-06122007> I don't see
how practical and how much are used those in real life for "pages" of rich web
applications. Anyway </SPAN>I<SPAN class=453301016-06122007> just can't found a
better way to achieve all that and also have that level of accesibility.
Probably more aural features of html and css should be applied. I can custom CSS
classes for components/subcomponets so if those classes are styled well
enough it should work. If I'm right you can make aural properties using CSS
to help accesibility.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT size=2><FONT
color=#0000ff><SPAN class=453301016-06122007></SPAN></FONT></FONT></FONT><FONT
face="Trebuchet MS"><FONT size=2><FONT color=#0000ff><SPAN
class=453301016-06122007></SPAN></FONT></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS"><FONT size=2><FONT
color=#0000ff><SPAN class=453301016-06122007>Again... "one problem at the time
baby"...</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=453301016-06122007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=453301016-06122007> cheers,</SPAN></FONT></DIV>
<DIV><FONT face="Trebuchet MS" color=#0000ff size=2></FONT> </DIV>
<DIV align=left><SPAN class=250542422-20122006>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" align=left><?xml:namespace prefix
= st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:PersonName
ProductID="Sebastian Sastre " w:st="on"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'">Sebastian
Sastre</SPAN></st1:PersonName></P></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=es dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>De:</B> seaside-bounces@lists.squeakfoundation.org
[mailto:seaside-bounces@lists.squeakfoundation.org] <B>En nombre de </B>Boris
Popov<BR><B>Enviado el:</B> Jueves, 06 de Diciembre de 2007
13:50<BR><B>Para:</B> seaside@lists.squeakfoundation.org<BR><B>Asunto:</B> Re:
[Seaside] Seaside sessions and ajax<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>Semantically sound html = easier styling and better
accessibility. For instance screen readers place emphasis on h1 and h2 whereas
they mostly ignore text styling.<BR><BR>Cheers!<BR><BR>-Boris<BR>(Sent from a
BlackBerry)<BR><BR>----- Original Message -----<BR>From:
seaside-bounces@lists.squeakfoundation.org
<seaside-bounces@lists.squeakfoundation.org><BR>To: 'Seaside - general
discussion' <seaside@lists.squeakfoundation.org><BR>Sent: Thu Dec 06
07:38:13 2007<BR>Subject: RE: [Seaside] Seaside sessions and ajax<BR><BR>>
I don't want a DIV around all my components.<BR>><BR><BR>Thanks for the
reading Lukas. I make some commments on each.<BR><BR>> <A
href="http://www.whatstyle.net/articles/22/less_div_more_html">http://www.whatstyle.net/articles/22/less_div_more_html</A><BR><BR>Quoting
it's stronger argument:<BR>"It's cleaner, it has less code, and therefore;
less clutter and lower<BR>maintenance."<BR><BR>OK, I say: that is important if
you deal with that code as a direct author.<BR>Seasiders are not direct
authors of their html. Scriptaculousiders also<BR>aren't direct authors of
most javascritp they use. Seaside spits all<BR>serialized for you so you don't
have to worry about it. That fact makes that<BR>argument extreamely weak at
least for the most heavy part: lower<BR>maintenance.<BR>Just to illustrate:
all my wrapper divs are in 1 method of this seaside<BR>compoents family that
has 16 short lines (of those, 1 is the selector of the<BR>method, 2 are
comments and 3 are separations).<BR><BR>> <A
href="http://www.motive.co.nz/glossary/div.php">http://www.motive.co.nz/glossary/div.php</A><BR>><BR>This
author state he's counter divitis arguments in 3 parts:<BR>1. complex
code<BR>I already deactivated this.<BR><BR>2. Quoting: "A web designer might
add additional <div>s that are redundant<BR>(in terms of the final
design), but that allow for future revision to the<BR>design. In some cases,
redundant <div>s are required to account for<BR>variations in that way
that different web browsers interpret the CSS<BR>language."<BR><BR>Here is
being contradictive with himself by justifying why he do not make<BR>allways
what he promotes, so nothing to say.<BR><BR>3. Quoting: "Less-experienced
webpage authors will often use a <div> in<BR>place of a more
semantically-appropriate HTML element. For example, they<BR>might use a
<div> and CSS to style text to look like a heading, rather than<BR>using
an HTML heading element (<h1>, <h2>,<h3>, etc.)."<BR><BR>I
agree and should add that is *only* valued by webdesigners elite (which
I<BR>don't give a dime for). Not one single user will value more a heading
that<BR>looks like a header because it *is* a <h1> instead of a syled
<div> nor that<BR>will make you gain more money, so... as I stated, I
don't give a dime to<BR>HTML and or CSS beauty code. Html is conceptually poor
and is doing what it<BR>can to evolve so why I should be a devote admirer of a
languange designed<BR>bad from start? I'll, by no mean, be of the "beauty
html" religion. It's not<BR>a language for persons nor for machines. Let user
agents to deal with it.<BR><BR>End users don't want to look your html, they
should not and they ever will.<BR>So if costs are the problem I say that
technologies that spit html for you<BR>will make that argument
insignificant.<BR><BR>Besides they are talking mostly for pages that have
extreamely simple<BR>layouts: 1 (one) container (probably body)with 3 or 4
colums with a liquid<BR>center. I want/need and talking about here, of having
the chance of<BR>composing ANY seaside component (of this family) trivially in
an arbitrary<BR>order of magnitude with border layout (see example:<BR><A
href="http://extjs.com/deploy/dev/examples/layout/complex.html">http://extjs.com/deploy/dev/examples/layout/complex.html</A>).
I gave a quick<BR>look in the app I'm working on and counted 9 levels deep of
border layout to<BR>reach the div that wraps a button in a medium-simple form.
When I can I'll<BR>show you some so you can firebug that insane html (firebug
thank you for<BR>exist).<BR><BR>> > The fact is that didn't stop me yet
of doing anything. Besides<BR>> > behavior, if you're valuing the
elegance of the html I would agree.<BR>> > The html would seem heavy but
todays it can travel deflated<BR>> by apache.<BR>> > Besides The
structure of what I have rendered on the user agent is<BR>> > kind of
homogeneus in nature even in a high degree of<BR>> composition. I<BR>>
> know that it should be the designer's problem but I think I've
also<BR>> > have solved a priori most of the positioning problems with
this. By<BR>> > having a little painful experience on layouting things
in<BR>> html you may know how valuable this could be.<BR>><BR>> I
don't see how these DIVs could be valuable for a designer,<BR>> as they are
probably auto generated. What worried me<BR>> initially was that I had the
impression that you wanted to<BR>> put a DIV around every
component.<BR>><BR>I may not let that clear enough. I don't want to force
anything in Seaside<BR>normal components hierarchy. Just a family of
components that work like<BR>this. Designers 99.9% probably get scared when
see that html because they<BR>are so used to manage html manually or
semi-manually. But they should not.<BR>This industrial way of using divs is
meant to provide power. Power when you<BR>use them with an associated CSS
class (that by the way I also generate<BR>automatically). The worst for
webdesigners is the part they'll see<BR>compromised CSS cascading
capabilities. Several properties are repeated in<BR>the CSS but is not that
bad as it sounds. OK, my CSS is 14KB and it is<BR>promising keep growing
firmly but it goes deflated and ends cached anyway.<BR><BR>> > So I say
we can scale<BR>> > that to make a family of components that are also
AJAXianly<BR>> backtrackeable.<BR>> > Those components have the trade
off of having to be identifiable in<BR>> > the DOM and capable of
setting it's innerHTML (that's why<BR>> I've choosed<BR>> > to wrapp
with div containers).<BR>><BR>> That makes sense.<BR>><BR>> >
If those components have to exists in a different hierarchy<BR>> other
than<BR>> > WAComponent let's be it.<BR>><BR>> Sure that's a
detail. I don't see any problems in starting<BR>> with a subclass of
WAComonent, I just feel that maybe later<BR>> on you might want to choose a
different superclass.<BR>> WAComponent provides a lot of functionality that
might not be<BR>> too useful in your context.<BR>><BR>OK, later we can
review that in the name of refactoring and clean Smalltalk<BR>code
:)<BR><BR>> > I thought in continuations because how Seaside works.
Suposing AJAX<BR>> > did not exists, Seaside maps one unique url
per<BR>> reandereable action.<BR>> > What I was thinking is that we
can map those rendereable<BR>> actions also<BR>> > to AJAX style of
render elements: updaters. If the problem<BR>> to solve is<BR>> >
backtrack rendereable actions, no matter if they are full<BR>> or
partial,<BR>> > I think Seaside is the winner because of continuations
(I say this<BR>> > because one can go back and forward in different
"branches"<BR>> of actions<BR>> > and as far as I know only
continuations handle that).<BR>><BR>> So far, I don't see any use of
continuations. Seaside only<BR>> uses continuations to wait in the middle
of a method for the<BR>> next request, e.g. with #call: and #answer:. The
state<BR>> backtracking has nothing to do with continuations (with
the<BR>> exception of the method-temps that are part of a suspended
method).<BR>><BR>Now you let me thinking!.. I didn't realize that. I should
take a reading on<BR>how those methods work. Oh, I get it with the updaters we
are not<BR>interrupting any method execution in the middle right? Sure man,
that is<BR>only a need if we want to make a kind of #call: to works with AJAX.
Ok, this<BR>is the "one problem at the time baby" hour so we let that for a
second<BR>stage, I bet is solvable.<BR><BR>So I need to understand better how
Seaside maintain things backtrakable.<BR>What do you suggest me to
read?<BR><BR>
Cheers,<BR><BR>Sebastian<BR><BR>> > I'm still thinking loud here so
please feel free to feedback,<BR>><BR>> Interesting
discussion.<BR>><BR>> Cheers,<BR>> Lukas<BR>><BR>> --<BR>>
Lukas Renggli<BR>> <A
href="http://www.lukas-renggli.ch">http://www.lukas-renggli.ch</A><BR>>
_______________________________________________<BR>> seaside mailing
list<BR>> seaside@lists.squeakfoundation.org<BR>> <A
href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR><BR>_______________________________________________<BR>seaside
mailing list<BR>seaside@lists.squeakfoundation.org<BR><A
href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR></FONT></P></BLOCKQUOTE></BODY></HTML>