[Seaside] Some questions about Seaside architecture

[Oleg Mürk]

Hello,

On 12/13/05, Cees De Groot <cdegroot at gmail.com> wrote:
>
> >  Returning to application state, that is not valid any more:
> >  * Edit record, archive record (so that one cannot edit it any more),
> > back-back, edit archived record.
>
> This is of course possible in any web environment, by using the back
> button. So you need to deal with this in any case. Seaside makes it
> possible to deal with it in a very clean way (which will help
> motivating your developers to pay attention to this)


If 10 developers have to do it 1000 times during 2 years, in how many times
they will forget it or do it wrong? My bet is 5%.

Hacks to defeat the back button are just that - hacks. They break the
> user's web browser experience, and they cannot be used to lock down
> the application - it is trivial to defeat any back button hack. So
> your best bet is to accept the back button as a fact of life, and use
> a web development environment that supports is well.


I don't agree with You. I don't want to start philosophical discussion
whether rich UI should have back button (my opinion is NO, Your opinion
is clearly YES). But there ARE very clean ways to forbid back button.

For instance:
* Application must be able to rerender itself without side effects
* Each response returns with (sequentially incremented) sequence ID
* If web server receives stale sequence ID, it just rerenders the
application's
   last state and goes on. Optionally one could also display warning
message.

But usability is a philosophical issue :)

OM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://liststest.squeakfoundation.org/pipermail/seaside/attachments/20051213/a31a9a7b/attachment.html