Hi list,
I'm playing with some ideas at the moment and someone asked whether we shouldn't get rid of WARegistry in the process. Are many people using or subclassing WARegistry? If you are, could you share what you're doing with it? Cheers, Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2011/5/27 Julian Fitzell <[hidden email]>:
> Hi list, > > I'm playing with some ideas at the moment and someone asked whether we > shouldn't get rid of WARegistry in the process. > … I would support that in favor of a dedicated session store and a dedicated document store. The current solution with document handlers and sessions stored is quite messy for example because sessions can be looked by cookie but documents can't. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Julian Fitzell-2
I subclass sessions big time. I never felt the need to do anything with WARegistry.
Never need to subclass it. o/ On May 27, 2011, at 5:13 AM, Julian Fitzell wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
+1.
Sent from my iPhone On 2011-05-27, at 5:08 AM, "Philippe Marschall" <[hidden email]> wrote: > 2011/5/27 Julian Fitzell <[hidden email]>: >> Hi list, >> >> I'm playing with some ideas at the moment and someone asked whether we >> shouldn't get rid of WARegistry in the process. >> … > > I would support that in favor of a dedicated session store and a > dedicated document store. The current solution with document handlers > and sessions stored is quite messy for example because sessions can be > looked by cookie but documents can't. > > 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 |
In reply to this post by Philippe Marschall
On Fri, May 27, 2011 at 10:08 AM, Philippe Marschall
<[hidden email]> wrote: > 2011/5/27 Julian Fitzell <[hidden email]>: >> Hi list, >> >> I'm playing with some ideas at the moment and someone asked whether we >> shouldn't get rid of WARegistry in the process. >> … > > I would support that in favor of a dedicated session store and a > dedicated document store. The current solution with document handlers > and sessions stored is quite messy for example because sessions can be > looked by cookie but documents can't. Yep, definitely part of what I'm playing with (though slightly tangential). It wouldn't be hard to accommodate WARegistry as a concept (a Dispatcher with dynamic keys, maybe or maybe not expiring - but probably without cookie support) but I think WAApplication will end up not being a subclass if this idea works out. I'm still interested in hearing from the list more generally - if you're using WARegistry for anything, please speak up. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I guess I just use WAApplication for everything... seeing as I how I don't understand any of the underlying architecture, I'm with whatever as long as I can still make an entry point ;)
RS
> From: [hidden email] > Date: Fri, 27 May 2011 14:10:22 +0100 > Subject: Re: [Seaside] WARegistry > To: [hidden email] > > On Fri, May 27, 2011 at 10:08 AM, Philippe Marschall > <[hidden email]> wrote: > > 2011/5/27 Julian Fitzell <[hidden email]>: > >> Hi list, > >> > >> I'm playing with some ideas at the moment and someone asked whether we > >> shouldn't get rid of WARegistry in the process. > >> … > > > > I would support that in favor of a dedicated session store and a > > dedicated document store. The current solution with document handlers > > and sessions stored is quite messy for example because sessions can be > > looked by cookie but documents can't. > > Yep, definitely part of what I'm playing with (though slightly > tangential). It wouldn't be hard to accommodate WARegistry as a > concept (a Dispatcher with dynamic keys, maybe or maybe not expiring - > but probably without cookie support) but I think WAApplication will > end up not being a subclass if this idea works out. > > I'm still interested in hearing from the list more generally - if > you're using WARegistry for anything, please speak up. > > Julian > _______________________________________________ > 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 |
In reply to this post by Julian Fitzell-2
We haven't found the need to subcass WARegistry for GLASS...
----- Original Message ----- > Hi list, > > I'm playing with some ideas at the moment and someone asked whether > we > shouldn't get rid of WARegistry in the process. Are many people using > or subclassing WARegistry? If you are, could you share what you're > doing with it? > > Cheers, > > Julian > _______________________________________________ > 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 |
In reply to this post by Julian Fitzell-2
On 05/27/2011 01:13 AM, Julian Fitzell wrote:
> Hi list, > > I'm playing with some ideas at the moment and someone asked whether we > shouldn't get rid of WARegistry in the process. Are many people using > or subclassing WARegistry? If you are, could you share what you're > doing with it? Never subclassed it directly, but subclass WAApplication plenty which is itself a WARegistry subclass. Usually I just want to get access to the request at the main application entry point before a particular session is invoked, a good example would be for rate limiting request using memcached or handling a response not meant for a session like a server heartbeat check from a load balancer or something. Maybe responding with a generated sitemap as well bypassing all the session machinery. -- Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Ive never subclassed it directly either. WASession is the only one ive used.
On Fri, May 27, 2011 at 9:00 AM, Ramon Leon <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Ramon Leon-5
2011/5/27 Ramon Leon <[hidden email]>:
> On 05/27/2011 01:13 AM, Julian Fitzell wrote: >> >> Hi list, >> >> I'm playing with some ideas at the moment and someone asked whether we >> shouldn't get rid of WARegistry in the process. Are many people using >> or subclassing WARegistry? If you are, could you share what you're >> doing with it? > > Never subclassed it directly, but subclass WAApplication plenty which is > itself a WARegistry subclass. Usually I just want to get access to the > request at the main application entry point before a particular session is > invoked, a good example would be for rate limiting request using memcached > or handling a response not meant for a session like a server heartbeat check > from a load balancer or something. Maybe responding with a generated > sitemap as well bypassing all the session machinery. Have you considered using request filters for this? Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Have you considered using request filters for this?
> > Cheers > Philippe It's a Seaside 2.8 app and very stable; haven't found a valid justification for upgrading something that works fine. People would scream at me if I broke things even for a short time. I see a lot of change in 3.0 for portability issues, cleaning up, and repackaging, but I see very little in the way of compelling new features. Am I wrong? -- Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2011/5/29 Ramon Leon <[hidden email]>:
>> Have you considered using request filters for this? >> >> Cheers >> Philippe > > It's a Seaside 2.8 app and very stable; haven't found a valid justification > for upgrading something that works fine. People would scream at me if I > broke things even for a short time. I see a lot of change in 3.0 for > portability issues, cleaning up, and repackaging, but I see very little in > the way of compelling new features. Am I wrong? Nope. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |