[Seaside] Seaside sessions and ajax

Thu Dec 6 17:54:24 UTC 2007

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.

    cheers,

Sebastian Sastre

  _____  

De: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] En nombre de Boris Popov
Enviado el: Jueves, 06 de Diciembre de 2007 14:26
Para: seaside at lists.squeakfoundation.org
Asunto: Re: [Seaside] Seaside sessions and ajax

Well, then you should just give that a go, trying to convince others will
only get in the way ;)

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: seaside-bounces at lists.squeakfoundation.org
<seaside-bounces at lists.squeakfoundation.org>
To: 'Seaside - general discussion' <seaside at lists.squeakfoundation.org>
Sent: Thu Dec 06 08:20:36 2007
Subject: RE: [Seaside] Seaside sessions and ajax

Hi Boris,

    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.

Again... "one problem at the time baby"...

    cheers,

Sebastian Sastre

________________________________

        De: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] En nombre de Boris Popov
        Enviado el: Jueves, 06 de Diciembre de 2007 13:50
        Para: seaside at lists.squeakfoundation.org
        Asunto: Re: [Seaside] Seaside sessions and ajax

        Semantically sound html = easier styling and better accessibility.
For instance screen readers place emphasis on h1 and h2 whereas they mostly
ignore text styling.

        Cheers!

        -Boris
        (Sent from a BlackBerry)

        ----- Original Message -----
        From: seaside-bounces at lists.squeakfoundation.org
<seaside-bounces at lists.squeakfoundation.org>
        To: 'Seaside - general discussion'
<seaside at lists.squeakfoundation.org>
        Sent: Thu Dec 06 07:38:13 2007
        Subject: RE: [Seaside] Seaside sessions and ajax

        > 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

        _______________________________________________
        seaside mailing list
        seaside at lists.squeakfoundation.org
        http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20071206/f4e73deb/attachment-0001.htm