Re: Re: [groovy-dev] grails: coding conventions write up
Graham,
Yes they are threadsafe, I think what Steven is emplying is that in
Grails the Controller take more responsibility than some web
frameworks for creating command objects and forwarding to Service
objects.
Controllers should really be singleton, which presents a thread safety issue..
The problem with this, I believe, is that it makes it more complex
than necessary and is not necessarily as simple as ROR (which is what
Grails will be competing with).
Graeme
On 7/1/05, Graham O'Regan <graham.oregan@...> wrote:
> I thought actions in WW were per-request, a throw-away object so
> thread-safety wasn't an issue? Or are you referring to the servlet as the
> controller?
>
> Some great ideas coming up here btw ;)
>
>
> Steven Devijver wrote:
> On 6/30/05, Guillaume Laforge <glaforge@...> wrote:
>
>
> On 30/06/05, Graeme Rocher <graeme.rocher@...> wrote:
>
>
> [...]
> Notice how I have not exposed the request and response objects and
> their complexities by default. There should be convenience maps
> automatically available like from the super class:
>
> params.myparam
> session.myprop
>
> Hmmm, with dependency injection, we could simply declare:
>
> <at> Property params
>
> And tada, the IoC container injects the params directly?
>
>
> Unfortunately that approach is not thread-safe. Controllers are meant
> to be singletons so parameters have to be passed along as parameters
> to methods or closures to ensure thread-safety.
>
> One thing I have been thinking about is a good Groovy abstraction for
> the request and response interfaces. Maps seem nice but then we only
> have the state without the behavior. But maps support in Groovy is
> nice so we should probably merge the Map interface with the
> HttpServletRequest and HttpServletResponse interfaces.
>
> If anyone wants to take a shot a this please feel free to do so.
>
>
>
>
> --
>
>
> Graham O'Regan
>
> Senior Developer
> Ellison Brookes
>
> w: http://www.ellisonbrookes.com
>
>
> The information contained in this communication is intended solely for the
> use of the individual or entity to whom it is addressed and others
> authorized to receive it. It may contain confidential or legally privileged
> information. If you are not the intended recipient you are hereby notified
> that any disclosure, copying, distribution or taking any action in reliance
> on the contents of this information is strictly prohibited and may be
> unlawful. If you have received this communication in error, please notify us
> immediately by responding to this email and then delete it from your system.
> Ellison Brookes is neither liable for the proper and complete transmission
> of the information contained in this communication nor for any delay in its
> receipt.
>
RSS Feed