Seaside sessions and ajax

Hello there,

i having few questions about how seaside handling ajax update requests.

I found that it handles differently, not like a regular page navigation.
For instance - continuation is not changing.

And i have a problem with sessions: when session expires, by default
we redirect page to show login page. But with ajax its just returns an
empty result, rendering updated page parts empty. How i can handle
session expiration with ajax correctly?

Also, i would like to make continuations updating for ajax, so any
user action regardless ajaxed or not with have new continuation id.
How this can be done?

Regard,
Igor
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I found that it handles differently, not like a regular page navigation.
> For instance - continuation is not changing.

Yes, AJAX handlers are executed (rendered) exactly the same way as a
callback would. This means it always evaluates the continuation of the
full page refresh, leading to several very subtle problems.

> And i have a problem with sessions: when session expires, by default
> we redirect page to show login page. But with ajax its just returns an
> empty result, rendering updated page parts empty. How i can handle
> session expiration with ajax correctly?

It does not return an empty result, but an error response. As you can
see in WAApplication>>#handleExpiredRequest: and its super
implementation WARegistry>>#handleExpiredRequest:. This allows you to
catch this case in the error handler #onFailure: of SUAjax (for one
particular AJAX handler) or SUResponders (for all AJAX handlers).

> Also, i would like to make continuations updating for ajax, so any
> user action regardless ajaxed or not with have new continuation id.
> How this can be done?

This is a thing on the to-do list of Seaside 2.8. Another related
problem is that the backtracking doesn't work (mildly expressed) with
AJAX. If you or anybody else has an idea about a possible solution to
these problem I would be glad to hear. So far I couldn't come up with
a nice solution myself ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks for reply!

On 18/05/07, Lukas Renggli <[hidden email]> wrote: so, i can add #onFailure: handler for my updater ?
can you please point to small code snippet using this. Im asking
because its pretty hard to express some meaningfull javascript
statements with current SUScript interface.
For example, for generating a simple javascript
if (...) { statements}  statements
i have a following horror code in smalltalk:

script := (renderer element id: elemId; hide;
                                        replace: '<div style="display:none" id="', elemId
,'">Loading...</div>'; return: false)
                                        condition: (renderer element id: elemId; visible);
                                        after:
                                                (renderer updater id: elemId;
                                                        callback: [ :html |  (self wikiViewerFor: helpObject)
renderViewerOn: html id: elemId ]),
                                                (renderer effect id: elemId; appear).

I think this must be changed to more convenient form for generating a
scripts by server.

And if you know how, please tell me how i can set a default OnFailure
handler in ajax, because putting onFailure: everywhere is too
excessive.

I don't think that ajax must support backtracking. It must be used for
atomic operations. Any other needs can be handled in general way,
bacause it adds too much complexity on top of what we already have,
gaining a minor bonuses.

I just need the seaside generate new continuation for Ajax requests.
Backtracking a javascript actions seem pointless to me.

About possible solution: suppose we already having a seaside
generating new continuation for each Ajax request.
Then on any answer we need to get new continuation id. And use this
new id for browser navigation. It means that all anchor/forms must use
this new id.
This can be done by changing the Href generation in seaside. Instead
of putting static _s,_k values, we need to put in all our Href-s a
call to javascript function, which composes requests based on current
_s, _k values received from last Ajax update request (or use initial
values if there was none of them).

Or, we can go in other way:
All what i need to have is, when user navigates via link, to preserve
the WAStateHolder values modified by Ajax requests invoked by some
user actions on page. Currently, seaside ignoring these changes and
reloads them from point when page was first loaded.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> so, i can add #onFailure: handler for my updater ?

Yes, that's the idea.

> can you please point to small code snippet using this.

You can find the full documentation here:

        http://www.prototypejs.org/api/ajax/options

For example the counter application could be modified to look like:

        html anchor
                onClick: (html updater
                        id: id;
                        onFailure: (SUScript new alert: 'Ouch, the session is gone');
                        callback: [ :render | self increase; renderCountOn: render ]);
                with: '++'.

> Im asking
> because its pretty hard to express some meaningfull javascript
> statements with current SUScript interface.
> For example, for generating a simple javascript
> if (...) { statements}  statements
> i have a following horror code in smalltalk:

Yes, that looks ugly. I have problems to understand, but I suspect ...

> I think this must be changed to more convenient form for generating a
> scripts by server.

Scriptaculous is not ment for that, but to interface with existing
Javascript code. I suggest that you write your functionality in an
external file and call it from the Scriptaculous tools. They are
designed to do that, not to write whole scripts.

> And if you know how, please tell me how i can set a default OnFailure
> handler in ajax, because putting onFailure: everywhere is too
> excessive.

You can set that on a per-handler bases, but pleas study the Protoypes
and script.aculo.us documentation for the details.

> I just need the seaside generate new continuation for Ajax requests.
> Backtracking a javascript actions seem pointless to me.

I don't want to backtrack Ajax requests, but to avoid that full
requests destroy what the Ajax requests have changed.

I am sure a lot of people don't want that. We generally try to keep
Seaside as Javascript free as possible. I know of many applications
that are supposed to run even without Javascript enabled.

I don't think that introducing new continuations solves the problem,
because it is not the ajax request that screws up the states but the
previous rendering request.

> All what i need to have is, when user navigates via link, to preserve
> the WAStateHolder values modified by Ajax requests invoked by some
> user actions on page. Currently, seaside ignoring these changes and
> reloads them from point when page was first loaded.

Yes, this is the point on the todo list for 2.8. The trick would be to
let the Ajax requests update the states of the last full rendering
request, however I didn't found a nice way to gasp that reference yet.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote:
> This is a thing on the to-do list of Seaside 2.8. Another related
> problem is that the backtracking doesn't work (mildly expressed) with
> AJAX. If you or anybody else has an idea about a possible solution to
> these problem I would be glad to hear. So far I couldn't come up with
> a nice solution myself ...

This will be a tough problem to solve, but will be important for all
future web applications.  Flash/Flex/whatever have the exact same (back
button) problem right now.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/5/20, Jason Johnson <[hidden email]>:
Flash doesn't have a back button -> problem solved.

Cheers
Philippe

> _______________________________________________
> 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

Philippe Marschall wrote:
>>
>> This will be a tough problem to solve, but will be important for all
>> future web applications.  Flash/Flex/whatever have the exact same (back
>> button) problem right now.
>
> Flash doesn't have a back button -> problem solved.

But all web pages that use flash do.  Problem not solved. :)
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> >> This will be a tough problem to solve, but will be important for all
> >> future web applications.  Flash/Flex/whatever have the exact same (back
> >> button) problem right now.
> >
> > Flash doesn't have a back button -> problem solved.
>
> But all web pages that use flash do.  Problem not solved. :)

Well I have sort of a fix. Unfortunately I had to patch Seaside core
methods in very ugly ways, as this requires some modifications in the
render-loop. I am not happy with it, because it brings a (memory)
overhead into the whole thing and I am not entirely sure if it's
really what we want in all cases. For the AJAX counter it works, but
maybe not for other cases. If I have time I can clean it a bit and
publish so that we see if all the trouble is worth the change ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 18/05/07, Lukas Renggli <[hidden email]> wrote: Well, i tried to add script,
but its simply don't rendered by updater, and i didn't find a way how.
Of course i can put just:  html tag:'script' -- but this is even
uglier than example above.
I tried to add html script: ...  to the end of updated part of page.
But then i see that
a #script: doing not exactly what i wanted. Instead of placing it in
HTML code at place where i said, it adds this script to the collection
which then will appear in HEAD tag.

> > And if you know how, please tell me how i can set a default OnFailure
> > handler in ajax, because putting onFailure: everywhere is too
> > excessive.
>
> You can set that on a per-handler bases, but pleas study the Protoypes
> and script.aculo.us documentation for the details.
>
Thanks for link with docs. I will study it to find possible solution.

Regards,
sig
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Lukas, all,

        I wonder again about the backbutton and ajax. How far or near we are
of making the user agent's back button and Seaside continuations magic to
work with updaters?

        If I want to help to achieve that where would be a place to start?
What readings do you have to suggest?

        cheers,

Sebastian Sastre


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>         I wonder again about the backbutton and ajax. How far or near we are
> of making the user agent's back button and Seaside continuations magic to
> work with updaters?

I never worked on this. So if nobody else was looking into that ...

>         If I want to help to achieve that where would be a place to start?
> What readings do you have to suggest?

Have a look at how other frameworks like DoJo, YUI and Google Web
Toolkit get the client side working. Be warned that all these
solutions are extremely hackish and only work on particular browser
versions. Then we can see how to integrate that JavaScript code into
Seaside.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Have a look at how other frameworks like DoJo, YUI and Google
> Web Toolkit get the client side working. Be warned that all
> these solutions are extremely hackish and only work on
> particular browser versions. Then we can see how to integrate
> that JavaScript code into Seaside.
>
> Cheers,
> Lukas
>
OK. So don't expect results any soon but we (mean community) need that
feature I'll start to explore those waters. I'll neigh if I found something
promising.

        cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

OK, I was reading a bit and for ajax and back button regard

1) seems that Yahoo is a winner in simplicity. Yahoo implemented it's
History Manager based on the RSH - Really Simply History framework (ref:
http://www.onjava.com/pub/a/onjava/2005/10/26/ajax-handling-bookmarks-and-ba
ck-button.html )

Their example seems amazing:
http://developer.yahoo.com/yui/examples/history/history-tabview.html

Could be that porting Bori's YUI to Squeak can be a starting point?

2) I've also see that they mention "the tricky part" when they need to
somehow reify the previous state, a thing that, for Seaside Continuations
should be a walk in the park. What I think we'll need is to identify DOM
elements and components 1:1.

I know Seaside does not do that by default by I see no exit for that. Things
seems to be scaling there (I value opinions here). I mean to the need of
having a DOM element wich is an homologue of the Seaside component.

I'm doing it and I'm very satisfied by it. To achieve that I'm using a
component hierarchy that wraps in a div whatever it has to render inside.
When I need to update any of those I know I can by making an updater to work
with it's id. Beside that server-side convenience I use to take advantage of
that id to perform user agent things among elements.

So what I'm saying is that if we need to identify updated elements
corresponding to seaside components we can do it. I don't know yet what will
happen with requestors and evaluators.

Beside that I think we could possibly need to identify updaters, evaluators
and requestors to relate them to a defined continuation. That way we make
YUI to use that unique callbak:

YAHOO.util.History.register ( componentId , initialState , onStateChange ,
obj , override )

I'm thinking about:
componentId <string> the id of the homologue of the seaside component
initialState <string> I don't yet get why they use a string to get such a
complexiy as a state thing. Maybe we don't use this at all.

onStateChange <function> the handler for the change of state. This is good,
here we can put the updater that can make things to go back one step.

obj <object> argument for the handler

override <boolean> if true, the obj passed in becomes the execution scope of
the listener.

        Any comments welcome,

        Cheers,

Sebastian Sastre
PS: Here is their API
http://developer.yahoo.com/yui/docs/YAHOO.util.History.html#register


 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I don't disagree with your approach, but you mentioned you wanted some input.

> "I'm using a
> component hierarchy that wraps in a div whatever it has to render inside"

I might be understanding you incorrectly, but it seems you want to  
wrap every component in a div (let me know if otherwise), or at least  
those you want the back button to reify the state with. I normally  
wrap things in divs anyway, so in that sense I do not have a problem,  
however in my experience doing something like that is not always a  
good idea.

For example, you might have a component that consists of just a  
textbox and a label, but you need some ajax calls on it. If you wrap  
it in a div, you introduce some CSS issues potentially and more  
importantly, you disrupt the semantic meaning of div in a document.  
What does a div mean? Should we really just put divs for the sake of  
code?

Personally, I'm not so obsessed with the "semantic correctness" of my  
html, however there are some cases where I try to keep it in mind. One  
of the main reasons is because how many screen readers work. I've run  
into this problem many times working with ASP.NET.

ASP.NET has a similar dynamic for state in general where a "control"  
get an ID that is used for restoring state information. That's a bit  
different then what you are doing with the back button I realize. The  
ASP.NET problem arises in that many of the so called "out-of-the-box"  
.NET controls output extra markup that screws up CSS, screen readers,  
and java scripts.

A second problem arises in ASP.NET with javascript in that because  
they map state and other things to control IDs, the output of the IDs  
must be unique per page. When you have components that can be 1-n  
controls, you are going to have to make sure all your IDs are unique  
unless you want some behavior otherwise. I can't even begin to tell  
you how many times I see unwanted/extra HTML output bite people in  
ASP.NET.

I use Seaside to get away from things like Struts, ASP.NET, etc. so I  
would not want to go down a similar road. Have you had a chance to  
look at any other frameworks in Python, Ruby, etc. and how they handle  
similar issues? Certainly continuations and other Seaside features  
introduce very different problems, but maybe we can find some points  
of reference.

I would really love a YUI integration or even EXT JS. Keep up the great work.

Quoting Sebastian Sastre <[hidden email]>:



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Their example seems amazing:
> http://developer.yahoo.com/yui/examples/history/history-tabview.html

It doesn't work in the first browser I tried :-(

> I know Seaside does not do that by default by I see no exit for that. Things
> seems to be scaling there (I value opinions here). I mean to the need of
> having a DOM element wich is an homologue of the Seaside component.

The question is, if Seaside components are really something that you
want? I know some AJAX heavy applications that just have one root
component, the rest is done trough renderable objects. Maybe it would
make sense instead of having a persistent component tree to have a
persistent DOM tree? A tree that can be backtracked and that knows
what gets modified, so that only changed parts are transmitted?

> I'm doing it and I'm very satisfied by it. To achieve that I'm using a
> component hierarchy that wraps in a div whatever it has to render inside.
> When I need to update any of those I know I can by making an updater to work
> with it's id. Beside that server-side convenience I use to take advantage of
> that id to perform user agent things among elements.

Generally this restricts the user too much in the way the XHTML is generated.

> Beside that I think we could possibly need to identify updaters, evaluators
> and requestors to relate them to a defined continuation. That way we make
> YUI to use that unique callbak:
>
> YAHOO.util.History.register ( componentId , initialState , onStateChange ,
> obj , override )

I don't really see the point of using continuations (yet). Of course
continuations are a cool solution to many problems, maybe not this
one. So I would start with the problem for now ;-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> It doesn't work in the first browser I tried :-(
>

So it must be Opera. Quoting Yahoo:
"Opera is not supported at this time. This is due to the fact that Opera
does not update the location.hash property when using the back/forward
buttons. We expect this regression to be corrected in a future version of
the Opera web browser."
I was reading about statistics and seems that Opera never reached 2% of a
market share that is not a half strategic Safari is.
OK, let's say all is done like that, I mean one root seaside compoenent and
the rest just another kind of rendereable objects, what have you gained by
doing that?
I don't get you on this. What kind of restrictions you mean? By user you
mean the user of Seaside, or final user?
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.
Actual Seaside components are solving the problem of backtraking actions
only for and coupled to full renders (maybe this is why you asked about if
seaside components are really what I want for this?). 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).
If those components have to exists in a different hierarchy other than
WAComponent let's be it.

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).

We can make the callback at onStateChange that the history manager calls to
execute an updater over the same dom element that matches the seaside
component with the seaside callback that will render the previous state.

I'm still thinking loud here so please feel free to feedback,

        Cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> So it must be Opera.

It is Safari, another unsupported browser.

I don't like hacks that are likely to break with the next service pack.

> OK, let's say all is done like that, I mean one root seaside compoenent and
> the rest just another kind of rendereable objects, what have you gained by
> doing that?

Just an idea. It might not work for you.

> I don't get you on this. What kind of restrictions you mean? By user you
> mean the user of Seaside, or final user?

I don't want a DIV around all my components.

  http://www.whatstyle.net/articles/22/less_div_more_html
  http://www.motive.co.nz/glossary/div.php

> 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.

> 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.

> 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).

> 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

> 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).
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.
OK, later we can review that in the name of refactoring and clean Smalltalk
code :)
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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

_______________________________________________
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 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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside