Cache vs old SpringCache: support for @Cacheable on controller closure actions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Cache vs old SpringCache: support for @Cacheable on controller closure actions

basejump (Josh)
Before I start peeling the onion back I wanted to see what the logic was here.
The old spring cache plugin supported @Cacheable on the action closures in a Controller.
Is there a reason why the new Cache plugin requires methods and does not support the old style of action declaration?

Also, is there already a replacement for this
http://gpc.github.com/grails-springcache/docs/guide/5.%20Cache%20Selection.html
Or will I need to spin something up myself?

Thanks

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

burtbeckwith
It would take a bit of work to support annotating closures, and with methods being preferred to closures for controller actions in 2.0+ it didn't make sense to expend the effort there.

There's no support for a cache resolver like in SpringCache, but it would be a good addition. If you do implement this please contribute it back.

Burt

basejump (Josh) wrote
Before I start peeling the onion back I wanted to see what the logic was here.
The old spring cache plugin supported @Cacheable on the action closures in a Controller.
Is there a reason why the new Cache plugin requires methods and does not support the old style of action declaration?

Also, is there already a replacement for this
http://gpc.github.com/grails-springcache/docs/guide/5.%20Cache%20Selection.html
Or will I need to spin something up myself?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

Mike Powers
The lack of closure support has actually caused us a small amount of pain when migrating from springcache -> cache plugin. For my project, it wasn't a problem converting closures to methods in controllers, but the closures in custom taglibs could not be cached. ( http://jira.grails.org/browse/GPCACHE-17 )

Other than that, the cache plugin as worked pretty well for us.


On Wed, Jan 30, 2013 at 10:05 PM, burtbeckwith <[hidden email]> wrote:
It would take a bit of work to support annotating closures, and with methods
being preferred to closures for controller actions in 2.0+ it didn't make
sense to expend the effort there.

There's no support for a cache resolver like in SpringCache, but it would be
a good addition. If you do implement this please contribute it back.

Burt


basejump (Josh) wrote
> Before I start peeling the onion back I wanted to see what the logic was
> here.
> The old spring cache plugin supported @Cacheable on the action closures in
> a Controller.
> Is there a reason why the new Cache plugin requires methods and does not
> support the old style of action declaration?
>
> Also, is there already a replacement for this
> http://gpc.github.com/grails-springcache/docs/guide/5.%20Cache%20Selection.html
> Or will I need to spin something up myself?
>
> Thanks





--
View this message in context: http://grails.1312388.n4.nabble.com/Cache-vs-old-SpringCache-support-for-Cacheable-on-controller-closure-actions-tp4640817p4640819.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

burtbeckwith
The plugin isn't anti-closure, just in controllers :)

Being able to cache taglib return values is on the todo list, we just didn't have time to do it for the initial release.

Burt

Mike Powers wrote
The lack of closure support has actually caused us a small amount of pain
when migrating from springcache -> cache plugin. For my project, it wasn't
a problem converting closures to methods in controllers, but the closures
in custom taglibs could not be cached. (
http://jira.grails.org/browse/GPCACHE-17 )

Other than that, the cache plugin as worked pretty well for us.
Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

Jeff Brown-4

On Jan 31, 2013, at 5:28 PM, burtbeckwith <[hidden email]> wrote:

> The plugin isn't anti-closure, just in controllers :)
>
> Being able to cache taglib return values is on the todo list, we just didn't
> have time to do it for the initial release.
>

Caching the return value might be useful for folks invoking tags as methods but for the more common use case I think caching the generated content (whatever is piped to "out") is what we want.  Is that correct?



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

Mike Powers
Hmm...Jeff, you bring up a interesting point. I have never considered the return value of a tag vs whats piped the 'out'. I created a simple test using the following tag:

def hello = { args ->
  out << "Hello"
  return "Grails"
}

When I call the tag from a gsp: <g:hello/>..."Hello" is displayed as expected. If I am in a controller, and invoke g.hello(), the return value is "Hello" (NOT "Grails"). I can say that I have never tried to explicitly return a value from a custom tag, the current Grails behavior seemed "right" :-)

Are there cases where you might expect / need a different return value from a tag compared to what is piped to out? Regardless, I believe the springcache plugin would cache the content piped to 'out'.


p.s. Our overall experience with the cache plugin has been very positive, I hope my first email didn't sound like I was complaining. Thanks for all the hard work!








On Thu, Jan 31, 2013 at 7:54 PM, Jeff Brown <[hidden email]> wrote:

On Jan 31, 2013, at 5:28 PM, burtbeckwith <[hidden email]> wrote:

> The plugin isn't anti-closure, just in controllers :)
>
> Being able to cache taglib return values is on the todo list, we just didn't
> have time to do it for the initial release.
>

Caching the return value might be useful for folks invoking tags as methods but for the more common use case I think caching the generated content (whatever is piped to "out") is what we want.  Is that correct?



JSB

--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

Jeff Brown-4

On Feb 1, 2013, at 11:48 AM, Mike Powers <[hidden email]> wrote:

> Hmm...Jeff, you bring up a interesting point. I have never considered the return value of a tag vs whats piped the 'out'. I created a simple test using the following tag:
>
> def hello = { args ->
>   out << "Hello"
>   return "Grails"
> }


I don't think you should do both (return a value and pipe stuff to out).  If the tag is returning a value you probably want something like this int he tag lib class…

    static returnObjectForTags = ['hello']




JSB
--
Jeff Brown
[hidden email]
SpringSource - A Division Of VMware
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

basejump (Josh)
In reply to this post by burtbeckwith
Makes sense. The problem we have is that we rely on the scaffolding for some of our controllers to provide base functionality.
The scaffolding , when using closure actions, works to replace if does not exists in the the actual controller.
see
http://grails.1312388.n4.nabble.com/Grails-2-controller-scaffold-how-to-override-a-template-method-td4640700.html
http://fbflex.wordpress.com/2012/11/26/a-subtle-difference-between-closures-and-closures-in-groovy/
http://jira.grails.org/browse/GRAILS-9614

We are trying NOT to create a BaseController class and have our controllers extend from that to override functionality using the preferred methods and @cacehable.
one of 2 things would need to happen in order not to create a baseController god super class
1. @cacheable support for closures
2. GRAILS-9614 fix

Any suggestions? Is Grails-9641 even worth digging into? From what I can tell it essentially works like a @mixin(if method/property not present)

On Jan 30, 2013, at 9:05 PM, burtbeckwith wrote:

> It would take a bit of work to support annotating closures, and with methods
> being preferred to closures for controller actions in 2.0+ it didn't make
> sense to expend the effort there.
>
> There's no support for a cache resolver like in SpringCache, but it would be
> a good addition. If you do implement this please contribute it back.
>
> Burt


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Cache vs old SpringCache: support for @Cacheable on controller closure actions

Mike Powers
Thanks for the response, and I completely agree about the return value of a tag. (My previous example was only to test how grails would behave with an explicit return value.)


On Fri, Feb 1, 2013 at 2:19 PM, Josh (basejump) <[hidden email]> wrote:
Makes sense. The problem we have is that we rely on the scaffolding for some of our controllers to provide base functionality.
The scaffolding , when using closure actions, works to replace if does not exists in the the actual controller.
see
http://grails.1312388.n4.nabble.com/Grails-2-controller-scaffold-how-to-override-a-template-method-td4640700.html
http://fbflex.wordpress.com/2012/11/26/a-subtle-difference-between-closures-and-closures-in-groovy/
http://jira.grails.org/browse/GRAILS-9614

We are trying NOT to create a BaseController class and have our controllers extend from that to override functionality using the preferred methods and @cacehable.
one of 2 things would need to happen in order not to create a baseController god super class
1. @cacheable support for closures
2. GRAILS-9614 fix

Any suggestions? Is Grails-9641 even worth digging into? From what I can tell it essentially works like a @mixin(if method/property not present)

On Jan 30, 2013, at 9:05 PM, burtbeckwith wrote:

> It would take a bit of work to support annotating closures, and with methods
> being preferred to closures for controller actions in 2.0+ it didn't make
> sense to expend the effort there.
>
> There's no support for a cache resolver like in SpringCache, but it would be
> a good addition. If you do implement this please contribute it back.
>
> Burt


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

    http://xircles.codehaus.org/manage_email