[Seaside] Seaside sessions and ajax

[smalltalk at fixinsbar.com]

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 <ssastre at seaswork.com>:

> 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
>
>
>
>
>> -----Mensaje original-----
>> De: seaside-bounces at lists.squeakfoundation.org
>> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre
>> de Lukas Renggli
>> Enviado el: Martes, 04 de Diciembre de 2007 04:52
>> Para: Seaside - general discussion
>> Asunto: Re: [Seaside] Seaside sessions and ajax
>>
>> >         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
>> 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
>