Seaside redirects, really?
Locked
123
123
Seaside redirects, really?
 
|
Hi guys,
please let me troll about seaside redirects... from the docs [1] one understands the basics of seaside requests processing: "...All subsequent requests are processed the same way. First, Seaside gives the components the ability to process the callbacks that have been defined during the last rendering pass. These callbacks are usually triggered by clicking a link or submitting a form. Then Seaside calls WAComponent>>updateUrl: of all visible components. This gives the developer the ability to modify the default URL automatically generated by Seaside. Then Seaside redirects the user to the new URL. This redirect is important, because it avoids processing the callbacks unnecessarily when the user hits the Back button. Finally Seaside renders the component tree..." so, here is what we know about seaside redirects 1. they add latency (UX on mobile seaside apps, hello?) 2. they complicate httpd configurations (and man! they don't need help to be a pain) 3. actually, seaside redirects complicate everything at a questionable price for a questionable gain (that's why I'm kicking the table about this) If you really care so much about state you already persisted the model, right? Conclusion: they're evil, they were overrated So? come on... I say seaside would be better without them (maybe way better) What you say? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On Sat, Oct 1, 2011 at 10:44 AM, Sebastian Sastre <[hidden email]> wrote:
Well ive never run into any problems with the redirects. But speedups are always good. What would you suggest to fix them? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
In reply to this post by sebastianconcept@gmail.co
2011/10/1 Sebastian Sastre <[hidden email]>:
> Hi guys, > please let me troll about seaside redirects... > from the docs [1] one understands the basics of seaside requests processing: > "...All subsequent requests are processed the same way. First, Seaside gives > the components the ability to process the callbacks that have been defined > during the last rendering pass. Uh oh, that's no longer true. > These callbacks are usually triggered by > clicking a link or submitting a form. Then Seaside calls > WAComponent>>updateUrl: of all visible components. This gives the developer > the ability to modify the default URL automatically generated by Seaside. > Then Seaside redirects the user to the new URL. This redirect is important, > because it avoids processing the callbacks unnecessarily when the user hits > the Back button. Finally Seaside renders the component tree..." > so, here is what we know about seaside redirects > 1. they add latency (UX on mobile seaside apps, hello?) > 2. they complicate httpd configurations (and man! they don't need help to be > a pain) How so? > 3. actually, seaside redirects complicate everything at a questionable price > for a questionable gain (that's why I'm kicking the table about this) What gets more complicated? > If you really care so much about state you already persisted the model, > right? You persist UI state (like which column is stored which way)? > Conclusion: they're evil, they were overrated > So? come on... I say seaside would be better without them (maybe way better) Nope, but if you feel that way you can disable them and live with the consequences (like that nice POST resubmission warning). > What you say? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 2, 2011, at 7:26 AM, Philippe Marschall wrote:
No. Not UI state. User preferences? probably yes. UX is King. So you persist whatever is valuable for the UX. Nope, but if you feel that way you can disable them and live with the There is currently a way to disable them? or you mean start hacking to get rid of them and see how it feels? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> There is currently a way to disable them? or
> you mean start hacking to get rid of them and see how it feels? Disabling only makes sense on certain links, that is if the link has no side-effects. You can tell the #anchor to #beNavigational to avoid the redirect in that particular case. For example, Pier uses this for the links that navigate between pages. To change it globally on can subclass (or patch) WAActionPhaseContinuation>>#shouldRedirect to answer false. This likely breaks the most simple Seaside application though. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
In reply to this post by sebastianconcept@gmail.co
2011/10/2 Sebastian Sastre <[hidden email]>:
> On Oct 2, 2011, at 7:26 AM, Philippe Marschall wrote: > > If you really care so much about state you already persisted the model, > > right? > > You persist UI state (like which column is stored which way)? > > No. Not UI state. See, that's why we need the redirect. So all the UI state that does not get persisted does not get messed up with the back or the reload button. > User preferences? probably yes. We do not talk about preferences. > UX is King. That's why we need the redirects so the back button and the refresh button don't break the application. > So you persist whatever is valuable for the UX. And that's UI state. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 2, 2011, at 12:30 PM, Philippe Marschall wrote:
yes I know what you mean. I'm using seaside after all. Is not that is a completely invalid way to see things of course. But the problem I have with that comes with the experience. Most of the times you have to make the components to know how to present a fresh view of the model either if the "rendered page" is coming from a back button click or a refresh button click or a click on a permalink. So if you have to design the app to make it capable to rebuild the presentations, then all the juggling to magically recover UI state is... less valuable (to put it softly) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
2011/10/2 Sebastian Sastre <[hidden email]>:
> > On Oct 2, 2011, at 12:30 PM, Philippe Marschall wrote: > > UX is King. > > That's why we need the redirects so the back button and the refresh > button don't break the application. > > yes I know what you mean. I'm using seaside after all. Is not that is a > completely invalid way to see things of course. > But the problem I have with that comes with the experience. > Most of the times you have to make the components to know how to present a > fresh view of the model either if the "rendered page" is coming from a back > button click or a refresh button click or a click on a permalink. > So if you have to design the app to make it capable to rebuild the > presentations, then all the juggling to magically recover UI state is... > less valuable (to put it softly) Sure, but then you shouldn't use Seaside. The problem is not the redirect at all but that you're using Seaside in a way it's not supposed to be used. That's why everything is not painful. If that's your problem then switch to an other framework. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 2, 2011, at 1:20 PM, Philippe Marschall wrote: you're using Seaside in a way it's not what you mean by that? that seaside isn't to
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
In reply to this post by Lukas Renggli
On Oct 2, 2011, at 11:58 AM, Lukas Renggli wrote: Disabling only makes sense on certain links, that is if the link has mm, nice... a starting point to play with _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
In reply to this post by sebastianconcept@gmail.co
2011/10/2 Sebastian Sastre <[hidden email]>:
> On Oct 2, 2011, at 1:20 PM, Philippe Marschall wrote: > > you're using Seaside in a way it's not > supposed to be used. > > what you mean by that? > that seaside isn't to > > present a > > fresh view of the model either if the "rendered page" is coming from a back > > button click or a refresh button click or a click on a permalink. Seaside doesn't read state from the request. You can do workarounds but use them judiciously. If you spend your time parsing requests, worrying about whether a request comes from a redirect, POST, callback, permalink or expired session you're doing it wrong. If you have all your "view state" in the URL you're definitively using the wrong framework. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
In reply to this post by Lukas Renggli
On Oct 2, 2011, at 11:58 AM, Lukas Renggli wrote: To change it globally on can subclass (or patch) so... expecting to see planes, bridges and buildings suddenly falling apart I've hacked WAActionPhaseContinuation>>#shouldRedirect to return false. Result? I have stuff working just right here. Not only that... this isn't scientific or anything, but by the preliminary numbers I'm seeing here when getting rid of the redirect makes things about 20-40% more responsive so... anybody want to share results? PD: in the hacked image the app has the url wrong because #updateUrl: uses the redirect. But that sounds pretty fixable to me. That if we are willing to try hard enough and we don't use that as a lame justification of crazy engineering _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
I get a sense you may have misunderstood the purpose of redirect in the first place, it's not there for fun and giggles ;) Sent from my iPhone
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 2, 2011, at 6:38 PM, Boris Popov, DeepCove Labs wrote: I get a sense you may have misunderstood the purpose of redirect in the first place, it's not there for fun and giggles ;) mm... wonder why could that matter if we can prove that: 1. we can live without it and 2. seaside apps suffer less from latency when you don't use them? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
2011/10/2 Sebastian Sastre <[hidden email]>:
> On Oct 2, 2011, at 6:38 PM, Boris Popov, DeepCove Labs wrote: > > I get a sense you may have misunderstood the purpose of redirect in the > first place, it's not there for fun and giggles ;) > > mm... > wonder why could that matter if we can prove that: > 1. we can live without it and You have proven nothing. The problems you mentioned at all have nothing at all to do with redirects. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by sebastianconcept@gmail.co
>> I get a sense you may have misunderstood the purpose of redirect in the
>> first place, it's not there for fun and giggles ;) > > mm... > wonder why could that matter if we can prove that: > 1. we can live without it and Millions of web applications have been written without programmatic HTML generation, without callback-based request handling, without embedded components, and without a modal session model; and still we decided to do it different. Similarly the redirects serve a well thought purpose. If you think these design decisions are not worth to paying for, you are probably better off using something else. > 2. seaside apps suffer less from latency when you don't use them? It is funny, that in the past 10 years nobody ever complained about that; and now that everybody is doing AJAX anyway this does not matter anymore (Seaside automatically avoids the redirect for AJAX calls). Lukas > sebastian > o/ > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 3, 2011, at 2:23 AM, Lukas Renggli wrote: Similarly the redirects serve a well which is what exactly? can you describe that well thought purpose? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>> Similarly the redirects serve a well
>> thought purpose. > > which is what exactly? > can you describe that well thought purpose? Decouple the callback processing from the rendering. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Mon, Oct 3, 2011 at 12:26 PM, Lukas Renggli <[hidden email]> wrote:
>>> Similarly the redirects serve a well >>> thought purpose. >> >> which is what exactly? >> can you describe that well thought purpose? > > Decouple the callback processing from the rendering. Thus ensuring that (a) hitting refresh doesn't re-trigger an action and (b) you don't get the browser dialog asking if you want to resubmit form data when you hit the Back button. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside redirects, really?
|
|
On Oct 3, 2011, at 8:29 AM, Julian Fitzell wrote: Similarly the redirects serve a wellthought purpose.which is what exactly?can you describe that well thought purpose?Decouple the callback processing from the rendering. okay those are reasons. Questions: for a: the refresh is an exception case, not the normal case, yet everything gets penalized because of that?for b: the browser opens that dialog only on POST requests only when the user press the back button, again an exceptional case but seaside it's penalizing every other request because of that? sorry but that sounds right or "well thought" to you? _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |