[Seaside] Seaside sessions and ajax
smalltalk at fixinsbar.com
smalltalk at fixinsbar.com
Thu Dec 6 19:51:42 UTC 2007
I agree, nothing beats constructive criticism. I liked to put my ideas
out there and see what people say so that I can draw on the experience
of others and factor in design problems I might not have otherwise seen.
FYI, I have been looking at AJAX toolkits a lot over the past few
years and for some reason, they seem to often be developed by people
who don't care about/use object oriented design principles. Maybe it's
because a lot of them are so called "web" developers or with all due
respect what I find to be a paradox, "PHP programmer."
I do concede doing things cross-browser is almost an impossibility. At
some point if you are going to use AJAX, you are going to have to make
compromises that you do not like. I would rather have a model that is
a joy to program with and lets me do a lot then one that does a lot
for me from the start but is a nightmare to use.
Quoting Sebastian Sastre <ssastre at seaswork.com>:
> 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
>
>
>
>
>
More information about the seaside
mailing list