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: [hidden email] <[hidden email]>
To: 'Seaside - general discussion' <[hidden email]>
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: [hidden email] [[hidden email]] En nombre de Boris Popov
        Enviado el: Jueves, 06 de Diciembre de 2007 13:50
        Para: [hidden email]
        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: [hidden email] <[hidden email]>
        To: 'Seaside - general discussion' <[hidden email]>
        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
        > [hidden email]
        > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
       
        _______________________________________________
        seaside mailing list
        [hidden email]
        http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
       

---

De: [hidden email] [mailto:[hidden email]] En nombre de Boris Popov
Enviado el: Jueves, 06 de Diciembre de 2007 14:26
Para: [hidden email]
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: [hidden email] <[hidden email]>
To: 'Seaside - general discussion' <[hidden email]>
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: [hidden email] [[hidden email]] En nombre de Boris Popov
        Enviado el: Jueves, 06 de Diciembre de 2007 13:50
        Para: [hidden email]
        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: [hidden email] <[hidden email]>
        To: 'Seaside - general discussion' <[hidden email]>
        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
        > [hidden email]
        > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
       
        _______________________________________________
        seaside mailing list
        [hidden email]
        http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside