Methods in services as opposed to closures

[Mike Finney]

Hi!

As indicated here in this 2009 copy, we should still always use methods in services as opposed to closures since some features "depend on method interception", right?

http://my.safaribooksonline.com/book/web-development/ruby/9781933988931/spring-and-transactions/398

This has not changed in the last two years. Correct?

I am asking because I see existing code which may need to be refactored into methods instead of closures. How much risk is there with the service using closures right now instead of methods? Knowing the risks would help with prioritizing.

Thanks!

--
Mike Finney - "Always Striving To Serve You Better Every Day"
http://www.SmilingSoftwareSolutions.com

[burtbeckwith]

One of those features is transaction support, so yeah - use methods in services :)

Are you using the fact that they're closures, or just being really really Groovy? Are you setting the delegate, or taking advantage of the fact that they're objects that can be passed as parameters to other closures or methods? If you're not then there's no reason at all to use a Closure.

Since they're just an object that Groovy treats like they're a method, interceptors don't see them. So they won't trigger transactional behavior, won't be intercepted by security interceptors, aren't candidates for remoting, etc.

Burt

> Hi!
>
> As indicated here in this 2009 copy, we should still always use methods in
> services as opposed to closures since some features "depend on method
> interception", right?
> http://my.safaribooksonline.com/book/web-development/ruby/9781933988931/spring-and-transactions/398
>
> This has not changed in the last two years. Correct?
>
> I am asking because I see existing code which may need to be refactored into
> methods instead of closures. How much risk is there with the service using
> closures right now instead of methods? Knowing the risks would help with
> prioritizing.
>
> Thanks!
>
>

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

    http://xircles.codehaus.org/manage_email

[sd]

Is there a way to rename the *.gz.js and *.gz.css files produced by the plugin to end with gz instead?
Nginx appears to only support serving already compressed files if they end in .gz using the gzip_static on option.
I could rename the files through a hook in _Events.groovy but the plugin itself configures the css includes based off the .gz.js name. I'm not sure why this naming convention was picked seeing it appears to differ from the standard format.

Thanks

[Ian Roberts]

On 10/07/2011 00:39, Burt Beckwith wrote:
> One of those features is transaction support, so yeah - use methods
> in services :)
>
> Are you using the fact that they're closures, or just being really
> really Groovy? Are you setting the delegate, or taking advantage of
> the fact that they're objects that can be passed as parameters to
> other closures or methods? If you're not then there's no reason at
> all to use a Closure.

And if you have a service method that you *do* need to use as a closure
in certain places you can use someService.&methodName to get a closure
that calls the method (this is standard Groovy syntax, not Grails-specific).

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

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

    http://xircles.codehaus.org/manage_email