- I've updated Gaelyk and the template project to using GAE SDK 1.3.5 and Groovy 1.7.3. - There are new variables in the binding, such as *app.id, app.version, app.env.name, and app.env.version*. - I added a *log variable in the binding*, so that you can easily log from groovlets and templates. - I updated the localMode binding variable implementation to use the new underlying environment information. - There are *new methods on BlobKey* to allow easy reading of the resource with an input stream or a reader (*withStream* and *withReader* ). - I've fixed some minor bugs. - And best for the end: there's now an experimental *Memcache caching support for groovlet and template output*, when specifying a cache duration in the URL routes.
- You can now add something like *cache: 10.seconds* at the end of your URL routes, to tell Gaelyk to store in Memcache the output of your groovlets and templates. - From some manual and non-scientific experiments, on some heavy pages, I've noticed the caching could improve the delivery of the page by 50% or so. Your mileage may obviously vary! - This feature works both for Groovlets and Templates. - Since only raw types like strings and byte arrays are stored in Memcache, I hope the cached output can resist a GAE loading requests. I'd love to hear from you on that, whether my assumption is true or not. That said, we can't totally escape the "loading request", since the application will have to be deployed before being able to serve the cached content! - There's some "last-modified" support, so a browser sending such requests shouldn't download the content again (and not fetch it again from the GAE memcache, but from the desktop browser local cache). I've not tested that very thouroughly though. I also haven't added ETag support either.
I said earlier that this feature is "*experimental*", as I've found a known issue: if you're using includes in your templates (ie. in the one you want to cache), the various outputs of all the templates is a bit mixed up, and I couldn't figure out why. So *I need your help*, and I'd really like to get an external pair of eyes to have a look at that and tell me what's wrong there, so that we can fix that for the next version.
I think that's all for tonight! Have fun with Gaelyk!
Thanks for all your hard work, Guillaume. I intend to take advantage of caching so I especially appreciate this feature though I will have to figure out how to implement routing into my app as I am not using the routing facility at this time though I had planed on going to a more restful url scheme.
A few months back I had mentioned in a post to the group that I had a problem using an include that was inside an each closure in my template files. It would cause the page rendering to abort after the 1st iteration of the closure. Being unable to rely on the include meant that I would have to hard code a common page element in all the pages that used it. I remember thinking at the time that the problem might have something to do the file io associated with opening the include more than once. Of course this was just a hunch but it might be worth looking at.
Thanks again for your dedication and commitment to Gaelyk.
Jeff
On Wed, Jul 7, 2010 at 7:01 PM, Guillaume Laforge <glafo...@gmail.com>wrote:
> - I've updated Gaelyk and the template project to using GAE SDK 1.3.5 > and Groovy 1.7.3. > - There are new variables in the binding, such as *app.id, app.version, > app.env.name, and app.env.version*. > - I added a *log variable in the binding*, so that you can easily log > from groovlets and templates. > - I updated the localMode binding variable implementation to use the > new underlying environment information. > - There are *new methods on BlobKey* to allow easy reading of the > resource with an input stream or a reader (*withStream* and *withReader > *). > - I've fixed some minor bugs. > - And best for the end: there's now an experimental *Memcache caching > support for groovlet and template output*, when specifying a cache > duration in the URL routes.
> - You can now add something like *cache: 10.seconds* at the end of your > URL routes, to tell Gaelyk to store in Memcache the output of your groovlets > and templates. > - From some manual and non-scientific experiments, on some heavy pages, > I've noticed the caching could improve the delivery of the page by 50% or > so. Your mileage may obviously vary! > - This feature works both for Groovlets and Templates. > - Since only raw types like strings and byte arrays are stored in > Memcache, I hope the cached output can resist a GAE loading requests. I'd > love to hear from you on that, whether my assumption is true or not. That > said, we can't totally escape the "loading request", since the application > will have to be deployed before being able to serve the cached content! > - There's some "last-modified" support, so a browser sending such > requests shouldn't download the content again (and not fetch it again from > the GAE memcache, but from the desktop browser local cache). I've not tested > that very thouroughly though. I also haven't added ETag support either.
> I said earlier that this feature is "*experimental*", as I've found a > known issue: if you're using includes in your templates (ie. in the one you > want to cache), the various outputs of all the templates is a bit mixed up, > and I couldn't figure out why. So *I need your help*, and I'd really like > to get an external pair of eyes to have a look at that and tell me what's > wrong there, so that we can fix that for the next version.
> I think that's all for tonight! > Have fun with Gaelyk!
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
Awesome work! I will upgrade as soon as possible. I really like
binding in the logger!
What is the easiest route to upgrade an existing project? Dropping the
new JARs
groovy-all*
gaelyk*
appengine-api*
into lib-folder and replacing the old ones?
Regards
//Daniel
On 8 Juli, 01:01, Guillaume Laforge <glafo...@gmail.com> wrote:
> - I've updated Gaelyk and the template project to using GAE SDK 1.3.5 and
> Groovy 1.7.3.
> - There are new variables in the binding, such as *app.id, app.version,
> app.env.name, and app.env.version*.
> - I added a *log variable in the binding*, so that you can easily log
> from groovlets and templates.
> - I updated the localMode binding variable implementation to use the new
> underlying environment information.
> - There are *new methods on BlobKey* to allow easy reading of the
> resource with an input stream or a reader (*withStream* and *withReader*
> ).
> - I've fixed some minor bugs.
> - And best for the end: there's now an experimental *Memcache caching
> support for groovlet and template output*, when specifying a cache
> duration in the URL routes.
> - You can now add something like *cache: 10.seconds* at the end of your
> URL routes, to tell Gaelyk to store in Memcache the output of your groovlets
> and templates.
> - From some manual and non-scientific experiments, on some heavy pages,
> I've noticed the caching could improve the delivery of the page by 50% or
> so. Your mileage may obviously vary!
> - This feature works both for Groovlets and Templates.
> - Since only raw types like strings and byte arrays are stored in
> Memcache, I hope the cached output can resist a GAE loading requests. I'd
> love to hear from you on that, whether my assumption is true or not. That
> said, we can't totally escape the "loading request", since the application
> will have to be deployed before being able to serve the cached content!
> - There's some "last-modified" support, so a browser sending such
> requests shouldn't download the content again (and not fetch it again from
> the GAE memcache, but from the desktop browser local cache). I've not tested
> that very thouroughly though. I also haven't added ETag support either.
> I said earlier that this feature is "*experimental*", as I've found a known
> issue: if you're using includes in your templates (ie. in the one you want
> to cache), the various outputs of all the templates is a bit mixed up, and I
> couldn't figure out why. So *I need your help*, and I'd really like to get
> an external pair of eyes to have a look at that and tell me what's wrong
> there, so that we can fix that for the next version.
> I think that's all for tonight!
> Have fun with Gaelyk!
On Thu, Jul 8, 2010 at 11:23, Dannemano <daniel.hedenst...@gmail.com> wrote: > Awesome work! I will upgrade as soon as possible. I really like > binding in the logger!
Glad you like it :-)
You'll just need to do: log.debug "foo" and tada!
> What is the easiest route to upgrade an existing project? Dropping the > new JARs > groovy-all* > gaelyk* > appengine-api* > into lib-folder and replacing the old ones?
Yup, normally, that should be all that is needed, just upgrade all the JARs and you're done.
> > - I've updated Gaelyk and the template project to using GAE SDK 1.3.5 > and > > Groovy 1.7.3. > > - There are new variables in the binding, such as *app.id, > app.version, > > app.env.name, and app.env.version*. > > - I added a *log variable in the binding*, so that you can easily log > > from groovlets and templates. > > - I updated the localMode binding variable implementation to use the > new > > underlying environment information. > > - There are *new methods on BlobKey* to allow easy reading of the > > resource with an input stream or a reader (*withStream* and > *withReader* > > ). > > - I've fixed some minor bugs. > > - And best for the end: there's now an experimental *Memcache caching > > support for groovlet and template output*, when specifying a cache > > duration in the URL routes.
> > Let's have a closer look at the caching aspect:
> > - You can now add something like *cache: 10.seconds* at the end of > your > > URL routes, to tell Gaelyk to store in Memcache the output of your > groovlets > > and templates. > > - From some manual and non-scientific experiments, on some heavy > pages, > > I've noticed the caching could improve the delivery of the page by 50% > or > > so. Your mileage may obviously vary! > > - This feature works both for Groovlets and Templates. > > - Since only raw types like strings and byte arrays are stored in > > Memcache, I hope the cached output can resist a GAE loading requests. > I'd > > love to hear from you on that, whether my assumption is true or not. > That > > said, we can't totally escape the "loading request", since the > application > > will have to be deployed before being able to serve the cached > content! > > - There's some "last-modified" support, so a browser sending such > > requests shouldn't download the content again (and not fetch it again > from > > the GAE memcache, but from the desktop browser local cache). I've not > tested > > that very thouroughly though. I also haven't added ETag support > either.
> > I said earlier that this feature is "*experimental*", as I've found a > known > > issue: if you're using includes in your templates (ie. in the one you > want > > to cache), the various outputs of all the templates is a bit mixed up, > and I > > couldn't figure out why. So *I need your help*, and I'd really like to > get > > an external pair of eyes to have a look at that and tell me what's wrong > > there, so that we can fix that for the next version.
> > I think that's all for tonight! > > Have fun with Gaelyk!
> > -- > > Guillaume Laforge > > Groovy Project Manager > > Head of Groovy Development at SpringSourcehttp:// > www.springsource.com/g2one
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
> Thanks for all your hard work, Guillaume. I intend to take advantage of
> caching so I especially appreciate this feature though I will have to figure
> out how to implement routing into my app as I am not using the routing
> facility at this time though I had planed on going to a more restful url
> scheme.
> A few months back I had mentioned in a post to the group that I had a
> problem using an include that was inside an each closure in my template
> files. It would cause the page rendering to abort after the 1st iteration of
> the closure. Being unable to rely on the include meant that I would have to
> hard code a common page element in all the pages that used it. I remember
> thinking at the time that the problem might have something to do the file io
> associated with opening the include more than once. Of course this was just
> a hunch but it might be worth looking at.
> Thanks again for your dedication and commitment to Gaelyk.
> Jeff
> On Wed, Jul 7, 2010 at 7:01 PM, Guillaume Laforge <glafo...@gmail.com>wrote:
> > Hi all,
> > I'm very pleased to announce the release of Gaelyk 0.4.1.
> > - I've updated Gaelyk and the template project to using GAE SDK 1.3.5
> > and Groovy 1.7.3.
> > - There are new variables in the binding, such as *app.id, app.version,
> > app.env.name, and app.env.version*.
> > - I added a *log variable in the binding*, so that you can easily log
> > from groovlets and templates.
> > - I updated the localMode binding variable implementation to use the
> > new underlying environment information.
> > - There are *new methods on BlobKey* to allow easy reading of the
> > resource with an input stream or a reader (*withStream* and *withReader
> > *).
> > - I've fixed some minor bugs.
> > - And best for the end: there's now an experimental *Memcache caching
> > support for groovlet and template output*, when specifying a cache
> > duration in the URL routes.
> > Let's have a closer look at the caching aspect:
> > - You can now add something like *cache: 10.seconds* at the end of your
> > URL routes, to tell Gaelyk to store in Memcache the output of your groovlets
> > and templates.
> > - From some manual and non-scientific experiments, on some heavy pages,
> > I've noticed the caching could improve the delivery of the page by 50% or
> > so. Your mileage may obviously vary!
> > - This feature works both for Groovlets and Templates.
> > - Since only raw types like strings and byte arrays are stored in
> > Memcache, I hope the cached output can resist a GAE loading requests. I'd
> > love to hear from you on that, whether my assumption is true or not. That
> > said, we can't totally escape the "loading request", since the application
> > will have to be deployed before being able to serve the cached content!
> > - There's some "last-modified" support, so a browser sending such
> > requests shouldn't download the content again (and not fetch it again from
> > the GAE memcache, but from the desktop browser local cache). I've not tested
> > that very thouroughly though. I also haven't added ETag support either.
> > I said earlier that this feature is "*experimental*", as I've found a
> > known issue: if you're using includes in your templates (ie. in the one you
> > want to cache), the various outputs of all the templates is a bit mixed up,
> > and I couldn't figure out why. So *I need your help*, and I'd really like
> > to get an external pair of eyes to have a look at that and tell me what's
> > wrong there, so that we can fix that for the next version.
> > I think that's all for tonight!
> > Have fun with Gaelyk!
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > Head of Groovy Development at SpringSource
> >http://www.springsource.com/g2one
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google
> > Groupes Gaelyk.
> > Pour envoyer un message à ce groupe, adressez un e-mail à
> > gaelyk@googlegroups.com.
> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com>
> > .
> > Pour plus d'options, consultez la page de ce groupe :
> >http://groups.google.com/group/gaelyk?hl=fr
On Thu, Jul 8, 2010 at 03:17, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > Thanks for all your hard work, Guillaume. I intend to take advantage of > caching so I especially appreciate this feature though I will have to figure > out how to implement routing into my app as I am not using the routing > facility at this time though I had planed on going to a more restful url > scheme.
I had wondered whether I should provide caching separately from routing, as these are two different concerns, but when the idea came to me that I could specify caching associated with the URL routes, it clicked.
There are some pros and cons of course.
Pros: - Nice way to integrate routing and caching - Avoid duplication of routing information: ie. one place to put the routes, and another place to define what should be cached, duplicating the URLs again - No need to create another filter to install to add caching to your application (as long as you use the URL routing filter)
Cons: - Well, you need to use the routing system, so if you didn't you have to, but on the other hand, that's nice to have more REST-ful URLs and not show the underlying technology used (ie. .gtpl and .groovy extensions) - The code is a bit more complicated than it should be in the routes filter, it makes me a bit uneasy here, and make me want to do some refactoring. That said, even if I do some refactoring in this area, the way to define caching for routes will stay the same.
A few months back I had mentioned in a post to the group that I had a
> problem using an include that was inside an each closure in my template > files. It would cause the page rendering to abort after the 1st iteration of > the closure. Being unable to rely on the include meant that I would have to > hard code a common page element in all the pages that used it. I remember > thinking at the time that the problem might have something to do the file io > associated with opening the include more than once. Of course this was just > a hunch but it might be worth looking at.
Under the hood, "include" really just does a JSP/servlet include. But it doesn't necessarily seem to play that well with Groovy's underlying script engine.
Looping and calling includes seems problematic (I haven't tried but I trust you :-)
Also, other problems: - includes are not URL routing friendly, as I can't "include" the content of a route (ie. using /myfriendlyurl vs /WEB-INF/includes/foo.gtpl) - the caching problem I mention: includes work and are inserted properly in the output when not cached, but the order is mixed up when cached
Perhaps it's time we think of a proper template inclusion mechanism instead :-(
> Thanks again for your dedication and commitment to Gaelyk.
I wish I could even spend more time on Gaelyk, lots of cool things to work on!
>> - I've updated Gaelyk and the template project to using GAE SDK 1.3.5 >> and Groovy 1.7.3. >> - There are new variables in the binding, such as *app.id, >> app.version, app.env.name, and app.env.version*. >> - I added a *log variable in the binding*, so that you can easily log >> from groovlets and templates. >> - I updated the localMode binding variable implementation to use the >> new underlying environment information. >> - There are *new methods on BlobKey* to allow easy reading of the >> resource with an input stream or a reader (*withStream* and * >> withReader*). >> - I've fixed some minor bugs. >> - And best for the end: there's now an experimental *Memcache caching >> support for groovlet and template output*, when specifying a cache >> duration in the URL routes.
>> Let's have a closer look at the caching aspect:
>> - You can now add something like *cache: 10.seconds* at the end of >> your URL routes, to tell Gaelyk to store in Memcache the output of your >> groovlets and templates. >> - From some manual and non-scientific experiments, on some heavy >> pages, I've noticed the caching could improve the delivery of the page by >> 50% or so. Your mileage may obviously vary! >> - This feature works both for Groovlets and Templates. >> - Since only raw types like strings and byte arrays are stored in >> Memcache, I hope the cached output can resist a GAE loading requests. I'd >> love to hear from you on that, whether my assumption is true or not. That >> said, we can't totally escape the "loading request", since the application >> will have to be deployed before being able to serve the cached content! >> - There's some "last-modified" support, so a browser sending such >> requests shouldn't download the content again (and not fetch it again from >> the GAE memcache, but from the desktop browser local cache). I've not tested >> that very thouroughly though. I also haven't added ETag support either.
>> I said earlier that this feature is "*experimental*", as I've found a >> known issue: if you're using includes in your templates (ie. in the one you >> want to cache), the various outputs of all the templates is a bit mixed up, >> and I couldn't figure out why. So *I need your help*, and I'd really like >> to get an external pair of eyes to have a look at that and tell me what's >> wrong there, so that we can fix that for the next version.
>> I think that's all for tonight! >> Have fun with Gaelyk!
>> -- >> Guillaume Laforge >> Groovy Project Manager >> Head of Groovy Development at SpringSource >> http://www.springsource.com/g2one
>> -- >> Vous recevez ce message, car vous êtes abonné au groupe Google >> Groupes Gaelyk. >> Pour envoyer un message à ce groupe, adressez un e-mail à >> gaelyk@googlegroups.com. >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse >> gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> >> . >> Pour plus d'options, consultez la page de ce groupe : >> http://groups.google.com/group/gaelyk?hl=fr
> -- > -- > Jeff
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
I just tried out the new caching functionality on my existing web app,
its crazy easy to enable. I did experience the jumbling of the
included templates (which makes it unusable for me right now), but I
also noticed that unicode characters did not display correctly when
being served from the cache. Has anyone else had this problem?
Cheers,
Royce
On Jul 8, 12:08 pm, Guillaume Laforge <glafo...@gmail.com> wrote:
> On Thu, Jul 8, 2010 at 03:17, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> > Thanks for all your hard work, Guillaume. I intend to take advantage of
> > caching so I especially appreciate this feature though I will have to figure
> > out how to implement routing into my app as I am not using the routing
> > facility at this time though I had planed on going to a more restful url
> > scheme.
> I had wondered whether I should provide caching separately from routing, as
> these are two different concerns, but when the idea came to me that I could
> specify caching associated with the URL routes, it clicked.
> There are some pros and cons of course.
> Pros:
> - Nice way to integrate routing and caching
> - Avoid duplication of routing information: ie. one place to put the routes,
> and another place to define what should be cached, duplicating the URLs
> again
> - No need to create another filter to install to add caching to your
> application (as long as you use the URL routing filter)
> Cons:
> - Well, you need to use the routing system, so if you didn't you have to,
> but on the other hand, that's nice to have more REST-ful URLs and not show
> the underlying technology used (ie. .gtpl and .groovy extensions)
> - The code is a bit more complicated than it should be in the routes filter,
> it makes me a bit uneasy here, and make me want to do some refactoring. That
> said, even if I do some refactoring in this area, the way to define caching
> for routes will stay the same.
> A few months back I had mentioned in a post to the group that I had a
> > problem using an include that was inside an each closure in my template
> > files. It would cause the page rendering to abort after the 1st iteration of
> > the closure. Being unable to rely on the include meant that I would have to
> > hard code a common page element in all the pages that used it. I remember
> > thinking at the time that the problem might have something to do the file io
> > associated with opening the include more than once. Of course this was just
> > a hunch but it might be worth looking at.
> Under the hood, "include" really just does a JSP/servlet include.
> But it doesn't necessarily seem to play that well with Groovy's underlying
> script engine.
> Looping and calling includes seems problematic (I haven't tried but I trust
> you :-)
> Also, other problems:
> - includes are not URL routing friendly, as I can't "include" the content of
> a route (ie. using /myfriendlyurl vs /WEB-INF/includes/foo.gtpl)
> - the caching problem I mention: includes work and are inserted properly in
> the output when not cached, but the order is mixed up when cached
> Perhaps it's time we think of a proper template inclusion mechanism instead
> :-(
> > Thanks again for your dedication and commitment to Gaelyk.
> I wish I could even spend more time on Gaelyk, lots of cool things to work
> on!
> Guillaume
> > Jeff
> > On Wed, Jul 7, 2010 at 7:01 PM, Guillaume Laforge <glafo...@gmail.com>wrote:
> >> Hi all,
> >> I'm very pleased to announce the release of Gaelyk 0.4.1.
> >> - I've updated Gaelyk and the template project to using GAE SDK 1.3.5
> >> and Groovy 1.7.3.
> >> - There are new variables in the binding, such as *app.id,
> >> app.version, app.env.name, and app.env.version*.
> >> - I added a *log variable in the binding*, so that you can easily log
> >> from groovlets and templates.
> >> - I updated the localMode binding variable implementation to use the
> >> new underlying environment information.
> >> - There are *new methods on BlobKey* to allow easy reading of the
> >> resource with an input stream or a reader (*withStream* and *
> >> withReader*).
> >> - I've fixed some minor bugs.
> >> - And best for the end: there's now an experimental *Memcache caching
> >> support for groovlet and template output*, when specifying a cache
> >> duration in the URL routes.
> >> Let's have a closer look at the caching aspect:
> >> - You can now add something like *cache: 10.seconds* at the end of
> >> your URL routes, to tell Gaelyk to store in Memcache the output of your
> >> groovlets and templates.
> >> - From some manual and non-scientific experiments, on some heavy
> >> pages, I've noticed the caching could improve the delivery of the page by
> >> 50% or so. Your mileage may obviously vary!
> >> - This feature works both for Groovlets and Templates.
> >> - Since only raw types like strings and byte arrays are stored in
> >> Memcache, I hope the cached output can resist a GAE loading requests. I'd
> >> love to hear from you on that, whether my assumption is true or not. That
> >> said, we can't totally escape the "loading request", since the application
> >> will have to be deployed before being able to serve the cached content!
> >> - There's some "last-modified" support, so a browser sending such
> >> requests shouldn't download the content again (and not fetch it again from
> >> the GAE memcache, but from the desktop browser local cache). I've not tested
> >> that very thouroughly though. I also haven't added ETag support either.
> >> I said earlier that this feature is "*experimental*", as I've found a
> >> known issue: if you're using includes in your templates (ie. in the one you
> >> want to cache), the various outputs of all the templates is a bit mixed up,
> >> and I couldn't figure out why. So *I need your help*, and I'd really like
> >> to get an external pair of eyes to have a look at that and tell me what's
> >> wrong there, so that we can fix that for the next version.
> >> I think that's all for tonight!
> >> Have fun with Gaelyk!
> >> --
> >> Guillaume Laforge
> >> Groovy Project Manager
> >> Head of Groovy Development at SpringSource
> >>http://www.springsource.com/g2one
> >> --
> >> Vous recevez ce message, car vous êtes abonné au groupe Google
> >> Groupes Gaelyk.
> >> Pour envoyer un message à ce groupe, adressez un e-mail à
> >> gaelyk@googlegroups.com.
> >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> >> gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com>
> >> .
> >> Pour plus d'options, consultez la page de ce groupe :
> >>http://groups.google.com/group/gaelyk?hl=fr
> > --
> > --
> > Jeff
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google
> > Groupes Gaelyk.
> > Pour envoyer un message à ce groupe, adressez un e-mail à
> > gaelyk@googlegroups.com.
> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com>
> > .
> > Pour plus d'options, consultez la page de ce groupe :
> >http://groups.google.com/group/gaelyk?hl=fr
On Thu, Jul 8, 2010 at 12:16, Royce Fullerton <roy...@gmail.com> wrote: > I just tried out the new caching functionality on my existing web app, > its crazy easy to enable.
Cool :-)
> I did experience the jumbling of the > included templates (which makes it unusable for me right now),
Yeah, there's really a problem with includes unfortunately :-(
Perhaps a better way would be to use something like SiteMesh for page layouting, and avoid includes. But we do need to include snippets / templates here and there, so we need to find a solution to the problem :-(
> also noticed that unicode characters did not display correctly when > being served from the cache. Has anyone else had this problem?
Ah yes, I notice that too :-( For a European like me with a language (French) with accents etc, I should have noticed that before the release! There's an encoding issue somewhere...
> On Jul 8, 12:08 pm, Guillaume Laforge <glafo...@gmail.com> wrote: > > Hi Jeff!
> > On Thu, Jul 8, 2010 at 03:17, Jeff Schwartz <jefftschwa...@gmail.com> > wrote: > > > Thanks for all your hard work, Guillaume. I intend to take advantage of > > > caching so I especially appreciate this feature though I will have to > figure > > > out how to implement routing into my app as I am not using the routing > > > facility at this time though I had planed on going to a more restful > url > > > scheme.
> > I had wondered whether I should provide caching separately from routing, > as > > these are two different concerns, but when the idea came to me that I > could > > specify caching associated with the URL routes, it clicked.
> > There are some pros and cons of course.
> > Pros: > > - Nice way to integrate routing and caching > > - Avoid duplication of routing information: ie. one place to put the > routes, > > and another place to define what should be cached, duplicating the URLs > > again > > - No need to create another filter to install to add caching to your > > application (as long as you use the URL routing filter)
> > Cons: > > - Well, you need to use the routing system, so if you didn't you have to, > > but on the other hand, that's nice to have more REST-ful URLs and not > show > > the underlying technology used (ie. .gtpl and .groovy extensions) > > - The code is a bit more complicated than it should be in the routes > filter, > > it makes me a bit uneasy here, and make me want to do some refactoring. > That > > said, even if I do some refactoring in this area, the way to define > caching > > for routes will stay the same.
> > A few months back I had mentioned in a post to the group that I had a
> > > problem using an include that was inside an each closure in my template > > > files. It would cause the page rendering to abort after the 1st > iteration of > > > the closure. Being unable to rely on the include meant that I would > have to > > > hard code a common page element in all the pages that used it. I > remember > > > thinking at the time that the problem might have something to do the > file io > > > associated with opening the include more than once. Of course this was > just > > > a hunch but it might be worth looking at.
> > Under the hood, "include" really just does a JSP/servlet include. > > But it doesn't necessarily seem to play that well with Groovy's > underlying > > script engine.
> > Looping and calling includes seems problematic (I haven't tried but I > trust > > you :-)
> > Also, other problems: > > - includes are not URL routing friendly, as I can't "include" the content > of > > a route (ie. using /myfriendlyurl vs /WEB-INF/includes/foo.gtpl) > > - the caching problem I mention: includes work and are inserted properly > in > > the output when not cached, but the order is mixed up when cached
> > Perhaps it's time we think of a proper template inclusion mechanism > instead > > :-(
> > > Thanks again for your dedication and commitment to Gaelyk.
> > I wish I could even spend more time on Gaelyk, lots of cool things to > work > > on!
> > Guillaume
> > > Jeff
> > > On Wed, Jul 7, 2010 at 7:01 PM, Guillaume Laforge <glafo...@gmail.com > >wrote:
> > >> Hi all,
> > >> I'm very pleased to announce the release of Gaelyk 0.4.1.
> > >> You can download Gaelyk, its JAR or the template project, from the > > >> download page: > > >>http://gaelyk.appspot.com/download
> > >> So what's new in this release?
> > >> - I've updated Gaelyk and the template project to using GAE SDK > 1.3.5 > > >> and Groovy 1.7.3. > > >> - There are new variables in the binding, such as *app.id, > > >> app.version, app.env.name, and app.env.version*. > > >> - I added a *log variable in the binding*, so that you can easily > log > > >> from groovlets and templates. > > >> - I updated the localMode binding variable implementation to use > the > > >> new underlying environment information. > > >> - There are *new methods on BlobKey* to allow easy reading of the > > >> resource with an input stream or a reader (*withStream* and * > > >> withReader*). > > >> - I've fixed some minor bugs. > > >> - And best for the end: there's now an experimental *Memcache > caching > > >> support for groovlet and template output*, when specifying a cache > > >> duration in the URL routes.
> > >> Let's have a closer look at the caching aspect:
> > >> - You can now add something like *cache: 10.seconds* at the end of > > >> your URL routes, to tell Gaelyk to store in Memcache the output of > your > > >> groovlets and templates. > > >> - From some manual and non-scientific experiments, on some heavy > > >> pages, I've noticed the caching could improve the delivery of the > page by > > >> 50% or so. Your mileage may obviously vary! > > >> - This feature works both for Groovlets and Templates. > > >> - Since only raw types like strings and byte arrays are stored in > > >> Memcache, I hope the cached output can resist a GAE loading > requests. I'd > > >> love to hear from you on that, whether my assumption is true or > not. That > > >> said, we can't totally escape the "loading request", since the > application > > >> will have to be deployed before being able to serve the cached > content! > > >> - There's some "last-modified" support, so a browser sending such > > >> requests shouldn't download the content again (and not fetch it > again from > > >> the GAE memcache, but from the desktop browser local cache). I've > not tested > > >> that very thouroughly though. I also haven't added ETag support > either.
> > >> I said earlier that this feature is "*experimental*", as I've found a > > >> known issue: if you're using includes in your templates (ie. in the > one you > > >> want to cache), the various outputs of all the templates is a bit > mixed up, > > >> and I couldn't figure out why. So *I need your help*, and I'd really > like > > >> to get an external pair of eyes to have a look at that and tell me > what's > > >> wrong there, so that we can fix that for the next version.
> > >> I think that's all for tonight! > > >> Have fun with Gaelyk!
> > >> -- > > >> Guillaume Laforge > > >> Groovy Project Manager > > >> Head of Groovy Development at SpringSource > > >>http://www.springsource.com/g2one
> > >> -- > > >> Vous recevez ce message, car vous êtes abonné au groupe Google > > >> Groupes Gaelyk. > > >> Pour envoyer un message à ce groupe, adressez un e-mail à > > >> gaelyk@googlegroups.com. > > >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > > >> gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > <gaelyk%2Bunsubscribe@googlegroups.com<gaelyk%252Bunsubscribe@googlegroups. com>
> > > -- > > > Vous recevez ce message, car vous êtes abonné au groupe Google > > > Groupes Gaelyk. > > > Pour envoyer un message à ce groupe, adressez un e-mail à > > > gaelyk@googlegroups.com. > > > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > > > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > <gaelyk%2Bunsubscribe@googlegroups.com<gaelyk%252Bunsubscribe@googlegroups. com>
> > -- > > Guillaume Laforge > > Groovy Project Manager > > Head of Groovy Development at SpringSourcehttp:// > www.springsource.com/g2one
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
On Thu, Jul 8, 2010 at 03:17, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > [...] > A few months back I had mentioned in a post to the group that I had a > problem using an include that was inside an each closure in my template > files. It would cause the page rendering to abort after the 1st iteration of > the closure.
Speaking of this...
I've just tried includes in groovlets and templates, including three times a template for example, and both examples worked!
Example with a groovlet:
html.html { body { 3.times { include "/WEB-INF/includes/snippet.gtpl"
On Thu, Jul 8, 2010 at 12:26, Guillaume Laforge <glafo...@gmail.com> wrote: > [...]
>> but I >> also noticed that unicode characters did not display correctly when >> being served from the cache. Has anyone else had this problem?
> Ah yes, I notice that too :-( > For a European like me with a language (French) with accents etc, I should > have noticed that before the release! > There's an encoding issue somewhere...
I have a fix for that. I'm hard-coding the fact UTF-8 should be used by default though, but I think it's a good practice nowadays. So in the next version, this aspect should be fixed. Sorry for that.
On Thu, Jul 8, 2010 at 12:16, Royce Fullerton <roy...@gmail.com> wrote: > I just tried out the new caching functionality on my existing web app, > its crazy easy to enable. I did experience the jumbling of the > included templates (which makes it unusable for me right now),
Back on the "jumbling" templates (I like the adjective :-), it's happening when caching templates with includes. However, there's not "jumbling" when caching groovlets with includes.
I no longer have the code that was problematic as when it didn't work I refactored everything using copy and paste to get beyond the issue but using pseudocode I was doing something along the lines of:
someList.each{ if(it.someThing){ <% include 'WEB-INF/includes/sometemplate.gtpl' %> }
}
the code in the template also referenced 'it'.
Not directly related to the issue but problematic none the less is that when a template raises an exception I am not able to determine where in the template the exception was raised by analyzing the stack trace. Is there some specific stack trace entry that points to the offending line when a template raises an exception?
On Thu, Jul 8, 2010 at 7:19 AM, Guillaume Laforge <glafo...@gmail.com>wrote:
> On Thu, Jul 8, 2010 at 03:17, Jeff Schwartz <jefftschwa...@gmail.com>wrote:
>> [...]
>> A few months back I had mentioned in a post to the group that I had a >> problem using an include that was inside an each closure in my template >> files. It would cause the page rendering to abort after the 1st iteration of >> the closure.
> Speaking of this...
> I've just tried includes in groovlets and templates, including three times > a template for example, and both examples worked!
> Example with a groovlet:
> html.html { > body { > 3.times { > include "/WEB-INF/includes/snippet.gtpl" > } > } > }
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
On Thu, Jul 8, 2010 at 14:23, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > I no longer have the code that was problematic as when it didn't work I > refactored everything using copy and paste to get beyond the issue but using > pseudocode I was doing something along the lines of:
<% [1, 2, 3].each { include "/WEB-INF/includes/snippet.gtpl?id=${it}" } %>
And it worked too (except with caching and the "jumbling" effect obviously).
the code in the template also referenced 'it'.
Here I used "it" as a parameter of the include, and it worked well (and my snippet.gtpl outputs the request param correctly)
Well, that's mysterious, but I don't seem to replicate the issue.
> Not directly related to the issue but problematic none the less is that > when a template raises an exception I am not able to determine where in the > template the exception was raised by analyzing the stack trace. Is there > some specific stack trace entry that points to the offending line when a > template raises an exception?
The exception handling of Groovy's template servlet (used by Gaelyk) is indeed a bit weird. Sometimes you get an error page, sometimes not but the output is cut after the point where the exception was raised. And, as you noticed, there's no real easy way to get back at the line where the problem occurred. In particular the last aspect is why I've been wondering about a full rewrite of the template servlet and/or a dedicated template engine that would not have the issues above, and that would help you figure out where the error was coming from. But a new template engine can be quite some work. So currently, when you see a stacktrace, there's no direct correspondance with line numbers in the stacktrace, and line numbers in the template. With a new template engine, we can maintain some kind of correspondance table, that would be handy.
I can imagine that implementing a new template engine would be quite a chore but it might be worth it if it allows for the types of includes that are now problematic with caching.
Regarding the issue I experienced with includes in a loop it occurred in an older version of Gaelyk so maybe it isn't an issue any longer. I will refactor one of my pages to use an include and give it a shot. I can't get to it right away but I will post back to the group the result.
On Thu, Jul 8, 2010 at 8:47 AM, Guillaume Laforge <glafo...@gmail.com>wrote:
> On Thu, Jul 8, 2010 at 14:23, Jeff Schwartz <jefftschwa...@gmail.com>wrote:
>> I no longer have the code that was problematic as when it didn't work I >> refactored everything using copy and paste to get beyond the issue but using >> pseudocode I was doing something along the lines of:
> And it worked too (except with caching and the "jumbling" effect > obviously).
> the code in the template also referenced 'it'.
> Here I used "it" as a parameter of the include, and it worked well (and my > snippet.gtpl outputs the request param correctly)
> Well, that's mysterious, but I don't seem to replicate the issue.
>> Not directly related to the issue but problematic none the less is that >> when a template raises an exception I am not able to determine where in the >> template the exception was raised by analyzing the stack trace. Is there >> some specific stack trace entry that points to the offending line when a >> template raises an exception?
> The exception handling of Groovy's template servlet (used by Gaelyk) is > indeed a bit weird. > Sometimes you get an error page, sometimes not but the output is cut after > the point where the exception was raised. > And, as you noticed, there's no real easy way to get back at the line where > the problem occurred. > In particular the last aspect is why I've been wondering about a full > rewrite of the template servlet and/or a dedicated template engine that > would not have the issues above, and that would help you figure out where > the error was coming from. > But a new template engine can be quite some work. > So currently, when you see a stacktrace, there's no direct correspondance > with line numbers in the stacktrace, and line numbers in the template. > With a new template engine, we can maintain some kind of correspondance > table, that would be handy.
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google > Groupes Gaelyk. > Pour envoyer un message à ce groupe, adressez un e-mail à > gaelyk@googlegroups.com. > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse > gaelyk+unsubscribe@googlegroups.com<gaelyk%2Bunsubscribe@googlegroups.com> > . > Pour plus d'options, consultez la page de ce groupe : > http://groups.google.com/group/gaelyk?hl=fr
