Quantcast

Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

pledbrook
> I very much hope the opposite. Keeping the controller request scope.
> and keep closure instead
> of method.

Having controller request scope means it's out of step with Spring
MVC. Is there a particular reason keeping them prototype beans? I
guess one argument is that it's easier to inject request-scoped
services and the like. To be honest, I could be persuaded either way
here.

I'm also interested in the arguments for using closure properties for
actions. Do you see a strong benefit to that approach?

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

Stephen Cresswell-2

An argument against closures is that you can't (afaik) wrap them with an AOP around advice. Therefore +1 to methods.

S

On 18 Nov 2010 09:03, "Peter Ledbrook" <[hidden email]> wrote:

> I very much hope the opposite. Keeping the controller request scope.
> and keep closure instead
> of method.

Having controller request scope means it's out of step with Spring
MVC. Is there a particular reason keeping them prototype beans? I
guess one argument is that it's easier to inject request-scoped
services and the like. To be honest, I could be persuaded either way
here.

I'm also interested in the arguments for using closure properties for
actions. Do you see a strong benefit to that approach?

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

smaldini
The both ways should be supported IMO. Why closures are used here ? Command objects args ? I agree that for unknown reason I find closures more elegants. But in another hand you don't have the same AOP facilities, you don't reuse actions unlike you reuse closures and you charge in memory properties to store this logic.

On Thu, Nov 18, 2010 at 1:18 PM, Stephen Cresswell <[hidden email]> wrote:

An argument against closures is that you can't (afaik) wrap them with an AOP around advice. Therefore +1 to methods.

S

On 18 Nov 2010 09:03, "Peter Ledbrook" <[hidden email]> wrote:

> I very much hope the opposite. Keeping the controller request scope.
> and keep closure instead
> of method.

Having controller request scope means it's out of step with Spring
MVC. Is there a particular reason keeping them prototype beans? I
guess one argument is that it's easier to inject request-scoped
services and the like. To be honest, I could be persuaded either way
here.

I'm also interested in the arguments for using closure properties for
actions. Do you see a strong benefit to that approach?

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Stéphane MALDINI
doc4web consultant 
On behalf of RSA, The Security Division of EMC - http://www.rsa.com 
[hidden email]
--
http://fr.linkedin.com/in/smaldini

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

ld@ldaley.com
In reply to this post by pledbrook

On 18/11/2010, at 7:02 PM, Peter Ledbrook wrote:

> Having controller request scope means it's out of step with Spring MVC. Is there a particular reason keeping them prototype beans?

Rails controllers are request scoped (which is what our controllers are in practice). However, the Rails controller instance becomes the model for the view which necessitates that approach.

> I guess one argument is that it's easier to inject request-scoped services and the like.

It is indeed easier, but it's not exactly difficult to use a scoped proxy these days and there are no longer issues with reloading when using scoped proxies.

There is a more subtle argument counter argument here in that when you start using scoped beans it could be a little confusing about what the scope of different Grails artefacts actually are and where you need to use proxies and where you don't. Moving to singletons would be more consistent, but this is a minor point.


My inclination at this point is that we SHOULD move to singletons and methods for 2.0.

I haven't measured, but you would assume that using singletons has to yield the same or better performance. I think we do need to measure this before deciding though.

As for methods, the ability to use AOP is significant enough to warrant the shift in my opinion. You cannot easily wrap closures in the same way that you can methods with Spring AOP. I have tried, it's impossible. The only thing you can do is replace the closure instance.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

Wilson MacGyver
In reply to this post by pledbrook
some of my reasons are rather subjective. Using closure instead of method
feels more elegant to me.

In terms of making controller singleton, the common argument I hear are
it's better for performance, or because spring MVC does it this way.

I question how much performance is gained by doing this. Request
scope is easier to reason with to me. I can't help but feel many
people use singleton wrong with shared variables and such.

As for "well, because spring MVC does it this way". Grails isn't a new project.
It's been around and has proven itself. More over, this means there is
legacy code out there.

To ask people to change their code so they can run it under 2.0 in such a
manner, I feel we need higher bar for reasons.


On Thu, Nov 18, 2010 at 4:02 AM, Peter Ledbrook <[hidden email]> wrote:

>> I very much hope the opposite. Keeping the controller request scope.
>> and keep closure instead
>> of method.
>
> Having controller request scope means it's out of step with Spring
> MVC. Is there a particular reason keeping them prototype beans? I
> guess one argument is that it's easier to inject request-scoped
> services and the like. To be honest, I could be persuaded either way
> here.
>
> I'm also interested in the arguments for using closure properties for
> actions. Do you see a strong benefit to that approach?
>
> Peter
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Omnem crede diem tibi diluxisse supremum.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

Stephen Cresswell-2

How about a config option - grails.controller.scope='singleton' with request being the default for backwards compatibility?

On 19 Nov 2010 07:58, "Wilson MacGyver" <[hidden email]> wrote:

some of my reasons are rather subjective. Using closure instead of method
feels more elegant to me.

In terms of making controller singleton, the common argument I hear are
it's better for performance, or because spring MVC does it this way.

I question how much performance is gained by doing this. Request
scope is easier to reason with to me. I can't help but feel many
people use singleton wrong with shared variables and such.

As for "well, because spring MVC does it this way". Grails isn't a new project.
It's been around and has proven itself. More over, this means there is
legacy code out there.

To ask people to change their code so they can run it under 2.0 in such a
manner, I feel we need higher bar for reasons.



On Thu, Nov 18, 2010 at 4:02 AM, Peter Ledbrook <[hidden email]> wrote:
>> I very much hope...

--
Omnem crede diem tibi diluxisse supremum.


---------------------------------------------------------------------
To unsubscribe from this list...

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

Graeme Rocher
Administrator
In reply to this post by ld@ldaley.com
On Fri, Nov 19, 2010 at 1:45 AM, Luke Daley <[hidden email]> wrote:
>
> On 18/11/2010, at 7:02 PM, Peter Ledbrook wrote:
>
>> Having controller request scope means it's out of step with Spring MVC. Is there a particular reason keeping them prototype beans?
>
> Rails controllers are request scoped (which is what our controllers are in practice). However, the Rails controller instance becomes the model for the view which necessitates that approach.


This happens in Grails as well. Try the following:

def books
def list = {
     books = Book.list()
}

Then in the view:

Total books ${books.size()}

If we were to change it would be a breaking change.

I personally am +1 for changing closures to methods (but supporting
closures still) and -1 for changing the scope to singleton because
object creation is relatively cheap (especially if we use methods and
not closures) and not having to reason about threading issues is a big
win IMO

A compromise would be to support the same thing we do as in services ie.

static scope = "singleton"

That way we could support both approaches (whilst defaulting to prototype)

Cheers


>
>> I guess one argument is that it's easier to inject request-scoped services and the like.
>
> It is indeed easier, but it's not exactly difficult to use a scoped proxy these days and there are no longer issues with reloading when using scoped proxies.
>
> There is a more subtle argument counter argument here in that when you start using scoped beans it could be a little confusing about what the scope of different Grails artefacts actually are and where you need to use proxies and where you don't. Moving to singletons would be more consistent, but this is a minor point.
>
>
> My inclination at this point is that we SHOULD move to singletons and methods for 2.0.
>
> I haven't measured, but you would assume that using singletons has to yield the same or better performance. I think we do need to measure this before deciding though.
>
> As for methods, the ability to use AOP is significant enough to warrant the shift in my opinion. You cannot easily wrap closures in the same way that you can methods with Spring AOP. I have tried, it's impossible. The only thing you can do is replace the closure instance.
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

Richard Bradley
> -1 for changing the scope to singleton because
> object creation is relatively cheap (especially if we use methods and
> not closures) and not having to reason about threading issues is a big
> win IMO

Same here


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Graeme Rocher
Sent: 19 November 2010 14:53
To: [hidden email]
Subject: Re: [grails-dev] Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

On Fri, Nov 19, 2010 at 1:45 AM, Luke Daley <[hidden email]> wrote:
>
> On 18/11/2010, at 7:02 PM, Peter Ledbrook wrote:
>
>> Having controller request scope means it's out of step with Spring MVC. Is there a particular reason keeping them prototype beans?
>
> Rails controllers are request scoped (which is what our controllers are in practice). However, the Rails controller instance becomes the model for the view which necessitates that approach.


This happens in Grails as well. Try the following:

def books
def list = {
     books = Book.list()
}

Then in the view:

Total books ${books.size()}

If we were to change it would be a breaking change.

I personally am +1 for changing closures to methods (but supporting
closures still) and -1 for changing the scope to singleton because
object creation is relatively cheap (especially if we use methods and
not closures) and not having to reason about threading issues is a big
win IMO

A compromise would be to support the same thing we do as in services ie.

static scope = "singleton"

That way we could support both approaches (whilst defaulting to prototype)

Cheers


>
>> I guess one argument is that it's easier to inject request-scoped services and the like.
>
> It is indeed easier, but it's not exactly difficult to use a scoped proxy these days and there are no longer issues with reloading when using scoped proxies.
>
> There is a more subtle argument counter argument here in that when you start using scoped beans it could be a little confusing about what the scope of different Grails artefacts actually are and where you need to use proxies and where you don't. Moving to singletons would be more consistent, but this is a minor point.
>
>
> My inclination at this point is that we SHOULD move to singletons and methods for 2.0.
>
> I haven't measured, but you would assume that using singletons has to yield the same or better performance. I think we do need to measure this before deciding though.
>
> As for methods, the ability to use AOP is significant enough to warrant the shift in my opinion. You cannot easily wrap closures in the same way that you can methods with Spring AOP. I have tried, it's impossible. The only thing you can do is replace the closure instance.
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



softwire
Richard Bradley
Tel : 020 7485 7500 ext 230 | Fax : 020 7485 7575
Web : www.softwire.com | E-mail : [hidden email]
Addr : 325 Highgate Studios, 53-79 Highgate Road, London NW5 1TL

Softwire Technology Limited. Registered in England no. 3824658. Registered Office : 13 Station Road, London N3 2SB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

ld@ldaley.com
In reply to this post by Graeme Rocher
On 20/11/2010, at 12:52 AM, Graeme Rocher <[hidden email]> wrote:

> On Fri, Nov 19, 2010 at 1:45 AM, Luke Daley <[hidden email]> wrote:
>>
>> On 18/11/2010, at 7:02 PM, Peter Ledbrook wrote:
>>
>>> Having controller request scope means it's out of step with Spring MVC. Is there a particular reason keeping them prototype beans?
>>
>> Rails controllers are request scoped (which is what our controllers are in practice). However, the Rails controller instance becomes the model for the view which necessitates that approach.
>
>
> This happens in Grails as well. Try the following:
>
> def books
> def list = {
>     books = Book.list()
> }
>
> Then in the view:
>
> Total books ${books.size()}
>
> If we were to change it would be a breaking change.

Which we should be cautious, but not overly scared of for 2.0.

> I personally am +1 for changing closures to methods (but supporting
> closures still)

Just for backwards compatability? If so  I am against this. It's another variant to support and another concern for plugin developers.

> and -1 for changing the scope to singleton because
> object creation is relatively cheap (especially if we use methods and
> not closures) and not having to reason about threading issues is a big
> win IMO

This seems to be the emerging consensus i.e. keeping current scoping but moving to methods.

> A compromise would be to support the same thing we do as in services ie.
>
> static scope = "singleton"
>
> That way we could support both approaches (whilst defaulting to prototype)
>
> Cheers
>
>
>>
>>> I guess one argument is that it's easier to inject request-scoped services and the like.
>>
>> It is indeed easier, but it's not exactly difficult to use a scoped proxy these days and there are no longer issues with reloading when using scoped proxies.
>>
>> There is a more subtle argument counter argument here in that when you start using scoped beans it could be a little confusing about what the scope of different Grails artefacts actually are and where you need to use proxies and where you don't. Moving to singletons would be more consistent, but this is a minor point.
>>
>>
>> My inclination at this point is that we SHOULD move to singletons and methods for 2.0.
>>
>> I haven't measured, but you would assume that using singletons has to yield the same or better performance. I think we do need to measure this before deciding though.
>>
>> As for methods, the ability to use AOP is significant enough to warrant the shift in my opinion. You cannot easily wrap closures in the same way that you can methods with Spring AOP. I have tried, it's impossible. The only thing you can do is replace the closure instance.
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Controller actions - methods or closures (was Re: [grails-dev] Statically typed meta programing)

smaldini


On Sat, Nov 20, 2010 at 1:12 AM, Luke Daley <[hidden email]> wrote:
On 20/11/2010, at 12:52 AM, Graeme Rocher <[hidden email]> wrote:

> On Fri, Nov 19, 2010 at 1:45 AM, Luke Daley <[hidden email]> wrote:
>>
>> On 18/11/2010, at 7:02 PM, Peter Ledbrook wrote:
>>
>>> Having controller request scope means it's out of step with Spring MVC. Is there a particular reason keeping them prototype beans?
>>
>> Rails controllers are request scoped (which is what our controllers are in practice). However, the Rails controller instance becomes the model for the view which necessitates that approach.
>
>
> This happens in Grails as well. Try the following:
>
> def books
> def list = {
>     books = Book.list()
> }
>
> Then in the view:
>
> Total books ${books.size()}
>
> If we were to change it would be a breaking change.

Which we should be cautious, but not overly scared of for 2.0.

> I personally am +1 for changing closures to methods (but supporting
> closures still)

Just for backwards compatability? If so  I am against this. It's another variant to support and another concern for plugin developers.

> and -1 for changing the scope to singleton because
> object creation is relatively cheap (especially if we use methods and
> not closures) and not having to reason about threading issues is a big
> win IMO

This seems to be the emerging consensus i.e. keeping current scoping but moving to methods.

> A compromise would be to support the same thing we do as in services ie.
>
> static scope = "singleton"


Default configuration for an application would be great like : grails.controllers.default.scope = 'singleton'. Some informations about threading issues should also be added in the future doc :)

 
>
> That way we could support both approaches (whilst defaulting to prototype)
>
> Cheers
>
>
>>
>>> I guess one argument is that it's easier to inject request-scoped services and the like.
>>
>> It is indeed easier, but it's not exactly difficult to use a scoped proxy these days and there are no longer issues with reloading when using scoped proxies.
>>
>> There is a more subtle argument counter argument here in that when you start using scoped beans it could be a little confusing about what the scope of different Grails artefacts actually are and where you need to use proxies and where you don't. Moving to singletons would be more consistent, but this is a minor point.
>>
>>
>> My inclination at this point is that we SHOULD move to singletons and methods for 2.0.
>>
>> I haven't measured, but you would assume that using singletons has to yield the same or better performance. I think we do need to measure this before deciding though.
>>
>> As for methods, the ability to use AOP is significant enough to warrant the shift in my opinion. You cannot easily wrap closures in the same way that you can methods with Spring AOP. I have tried, it's impossible. The only thing you can do is replace the closure instance.
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource - A Division of VMware
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Stéphane MALDINI
doc4web consultant 
On behalf of RSA, The Security Division of EMC - http://www.rsa.com 
[hidden email]
--
http://fr.linkedin.com/in/smaldini

Loading...