[Seaside] Seaside sessions and ajax

Boris Popov boris at deepcovelabs.com
Thu Dec 6 16:25:59 UTC 2007

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


(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"...
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.
	(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
	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
	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
	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
	> > 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?
	> > 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

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

More information about the seaside mailing list