<!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" color=#0000ff size=2><SPAN
class=812464717-06122007>For sure! but please don't get me wrong, at this stage
the only one I'm trying to convince is myself about exactly what
deserves the green light. The cheapest way I know to make the first
filtering of bad ideas is to expose things to persons that use
it's common sense and experience and are generous enough to criticize
smartly. If concept survive by itself then deserves more so I think that
experiments time on this is coming. Lets see what happen.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=812464717-06122007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face="Trebuchet MS" color=#0000ff size=2><SPAN
class=812464717-06122007> cheers,</SPAN></FONT></DIV>
<DIV> </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<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
/><o:p></o:p></SPAN></st1:PersonName></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Trebuchet MS'"><o:p></o:p></SPAN></P></DIV></SPAN>
<DIV><FONT face="Trebuchet MS" color=#0000ff size=2></FONT> </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
14:26<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>Well, then you should just give that a go, trying to convince
others will only get in the way ;)<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
08:20:36 2007<BR>Subject: RE: [Seaside] Seaside sessions and ajax<BR><BR>Hi
Boris,<BR><BR> I don't see how practical and how much are
used those in real life for "pages" of rich web applications. Anyway I 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.<BR><BR>Again... "one problem at the time
baby"...<BR><BR> cheers,<BR><BR>Sebastian
Sastre<BR><BR><BR>________________________________<BR><BR>
De: seaside-bounces@lists.squeakfoundation.org [<A
href="mailto:seaside-bounces@lists.squeakfoundation.org">mailto:seaside-bounces@lists.squeakfoundation.org</A>]
En nombre de Boris Popov<BR> Enviado
el: Jueves, 06 de Diciembre de 2007
13:50<BR> Para:
seaside@lists.squeakfoundation.org<BR>
Asunto: Re: [Seaside] Seaside sessions and
ajax<BR> <BR> <BR><BR>
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> <BR><BR></FONT></P></BLOCKQUOTE></BODY></HTML>