GroovyPagesTemplateEngine / GSP related re-design needed?

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

GroovyPagesTemplateEngine / GSP related re-design needed?

Lari Hotari -
Dear Grails devs,

There are several issues open to add better support for using GSPs for
these use cases:
* dynamic template engine (templates loaded from database / cms,
templates editable)
* usage as template engine outside the web-request processing (templates
from static gsp files, but rendering done in a background job)
Currently only the usage as Grails view layer "rendering engine" is
properly supported.

Correct usage as a dynamic template engine or outside web-request
processing aren't even documented in the Grails Manual.

Some of the Jira issues related to the subject:
http://jira.codehaus.org/browse/GRAILS-5560
http://jira.codehaus.org/browse/GRAILS-6809
http://jira.codehaus.org/browse/GRAILS-3818

There are also different concerns in the solution:

* template parsing/compilation
* template rendering/execution
* template/view resolution (DRY lookup logic etc.)
* template source loading / re-loading/expiration/lastmodified checks
* template caching

I don't think all usecases & concerns should be all
supported/implemented on the same interface or service bean (or even
same instance of a service bean).

If we continue adding features without re-design, most of the
implementation might end up in the GroovyPagesTemplateEngine which might
not be a good idea.

Any ideas about how to add better support for the 2 use cases (dynamic
template engine, usage outside web-request processing)?
Design? Roadmap/Schedule?

Lari

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Graeme Rocher
Administrator
This would have to go into a next major release (earliest being 1.4)

I would suggestion that GroovyPagesTemplateEngine is a bit too low
level and what we need is a new high-level API that provides methods
to easily render templates. Example:

interface GroovyPagesService {
         void renderTemplate(String templateText, Writer target)
         void renderTemplate(Reader templateText, Writer target)
         void renderTemplate(URI location, Writer target)
         void renderTemplate(String controller, String template, Writer target)
}

You could have variations of the API for modified checks etc.

The tricky thing is going to be handling the caching etc. without
leaking permgen.

Cheers


On Thu, Jan 13, 2011 at 10:34 AM, Lari Hotari <[hidden email]> wrote:

> Dear Grails devs,
>
> There are several issues open to add better support for using GSPs for these
> use cases:
> * dynamic template engine (templates loaded from database / cms, templates
> editable)
> * usage as template engine outside the web-request processing (templates
> from static gsp files, but rendering done in a background job)
> Currently only the usage as Grails view layer "rendering engine" is properly
> supported.
>
> Correct usage as a dynamic template engine or outside web-request processing
> aren't even documented in the Grails Manual.
>
> Some of the Jira issues related to the subject:
> http://jira.codehaus.org/browse/GRAILS-5560
> http://jira.codehaus.org/browse/GRAILS-6809
> http://jira.codehaus.org/browse/GRAILS-3818
>
> There are also different concerns in the solution:
>
> * template parsing/compilation
> * template rendering/execution
> * template/view resolution (DRY lookup logic etc.)
> * template source loading / re-loading/expiration/lastmodified checks
> * template caching
>
> I don't think all usecases & concerns should be all supported/implemented on
> the same interface or service bean (or even same instance of a service
> bean).
>
> If we continue adding features without re-design, most of the implementation
> might end up in the GroovyPagesTemplateEngine which might not be a good
> idea.
>
> Any ideas about how to add better support for the 2 use cases (dynamic
> template engine, usage outside web-request processing)?
> Design? Roadmap/Schedule?
>
> Lari
>
> ---------------------------------------------------------------------
> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Lari Hotari -
Could we separate the different concerns even more?

http://jira.codehaus.org/browse/GRAILS-5560 has a request for adding
"lastmodifed" parameter to the GroovyPagesTemplateEngine createTemplate
method. Would it make sense to separate template loading?

Something similar to the Freemarker TemplateLoader would be nice:
http://freemarker.sourceforge.net/docs/api/freemarker/cache/TemplateLoader.html
http://freemarker.sourceforge.net/docs/pgui_config_templateloading.html#autoid_38
In Freemarker it's easy to implement a TemplateLoader which loads
templates from a database , CMS etc..

Do we need something like this for GSPs (to better support the use as a
dynamic template engine)?

Lari


13.01.2011 11:43, Graeme Rocher wrote:

> This would have to go into a next major release (earliest being 1.4)
>
> I would suggestion that GroovyPagesTemplateEngine is a bit too low
> level and what we need is a new high-level API that provides methods
> to easily render templates. Example:
>
> interface GroovyPagesService {
>           void renderTemplate(String templateText, Writer target)
>           void renderTemplate(Reader templateText, Writer target)
>           void renderTemplate(URI location, Writer target)
>           void renderTemplate(String controller, String template, Writer target)
> }
>
> You could have variations of the API for modified checks etc.
>
> The tricky thing is going to be handling the caching etc. without
> leaking permgen.
>
> Cheers
>
>
> On Thu, Jan 13, 2011 at 10:34 AM, Lari Hotari<[hidden email]>  wrote:
>> Dear Grails devs,
>>
>> There are several issues open to add better support for using GSPs for these
>> use cases:
>> * dynamic template engine (templates loaded from database / cms, templates
>> editable)
>> * usage as template engine outside the web-request processing (templates
>> from static gsp files, but rendering done in a background job)
>> Currently only the usage as Grails view layer "rendering engine" is properly
>> supported.
>>
>> Correct usage as a dynamic template engine or outside web-request processing
>> aren't even documented in the Grails Manual.
>>
>> Some of the Jira issues related to the subject:
>> http://jira.codehaus.org/browse/GRAILS-5560
>> http://jira.codehaus.org/browse/GRAILS-6809
>> http://jira.codehaus.org/browse/GRAILS-3818
>>
>> There are also different concerns in the solution:
>>
>> * template parsing/compilation
>> * template rendering/execution
>> * template/view resolution (DRY lookup logic etc.)
>> * template source loading / re-loading/expiration/lastmodified checks
>> * template caching
>>
>> I don't think all usecases&  concerns should be all supported/implemented on
>> the same interface or service bean (or even same instance of a service
>> bean).
>>
>> If we continue adding features without re-design, most of the implementation
>> might end up in the GroovyPagesTemplateEngine which might not be a good
>> idea.
>>
>> Any ideas about how to add better support for the 2 use cases (dynamic
>> template engine, usage outside web-request processing)?
>> Design? Roadmap/Schedule?
>>
>> Lari
>>
>> ---------------------------------------------------------------------
>> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Graeme Rocher
Administrator
Well the idea of using the Spring Resource abstraction was to allow you to load from different a database, CMS etc.

The Resource API abstracts the source of the resource and you should be able to specify a different resource loader.

For example at the moment we using GroovyPagesResourceLoader I believe

Cheers
Graeme

On 13 Jan 2011, at 10:56, Lari Hotari wrote:

> Could we separate the different concerns even more?
>
> http://jira.codehaus.org/browse/GRAILS-5560 has a request for adding
> "lastmodifed" parameter to the GroovyPagesTemplateEngine createTemplate
> method. Would it make sense to separate template loading?
>
> Something similar to the Freemarker TemplateLoader would be nice:
> http://freemarker.sourceforge.net/docs/api/freemarker/cache/TemplateLoader.html
> http://freemarker.sourceforge.net/docs/pgui_config_templateloading.html#autoid_38
> In Freemarker it's easy to implement a TemplateLoader which loads
> templates from a database , CMS etc..
>
> Do we need something like this for GSPs (to better support the use as a
> dynamic template engine)?
>
> Lari
>
>
> 13.01.2011 11:43, Graeme Rocher wrote:
>> This would have to go into a next major release (earliest being 1.4)
>>
>> I would suggestion that GroovyPagesTemplateEngine is a bit too low
>> level and what we need is a new high-level API that provides methods
>> to easily render templates. Example:
>>
>> interface GroovyPagesService {
>>          void renderTemplate(String templateText, Writer target)
>>          void renderTemplate(Reader templateText, Writer target)
>>          void renderTemplate(URI location, Writer target)
>>          void renderTemplate(String controller, String template, Writer target)
>> }
>>
>> You could have variations of the API for modified checks etc.
>>
>> The tricky thing is going to be handling the caching etc. without
>> leaking permgen.
>>
>> Cheers
>>
>>
>> On Thu, Jan 13, 2011 at 10:34 AM, Lari Hotari<[hidden email]>  wrote:
>>> Dear Grails devs,
>>>
>>> There are several issues open to add better support for using GSPs for these
>>> use cases:
>>> * dynamic template engine (templates loaded from database / cms, templates
>>> editable)
>>> * usage as template engine outside the web-request processing (templates
>>> from static gsp files, but rendering done in a background job)
>>> Currently only the usage as Grails view layer "rendering engine" is properly
>>> supported.
>>>
>>> Correct usage as a dynamic template engine or outside web-request processing
>>> aren't even documented in the Grails Manual.
>>>
>>> Some of the Jira issues related to the subject:
>>> http://jira.codehaus.org/browse/GRAILS-5560
>>> http://jira.codehaus.org/browse/GRAILS-6809
>>> http://jira.codehaus.org/browse/GRAILS-3818
>>>
>>> There are also different concerns in the solution:
>>>
>>> * template parsing/compilation
>>> * template rendering/execution
>>> * template/view resolution (DRY lookup logic etc.)
>>> * template source loading / re-loading/expiration/lastmodified checks
>>> * template caching
>>>
>>> I don't think all usecases&  concerns should be all supported/implemented on
>>> the same interface or service bean (or even same instance of a service
>>> bean).
>>>
>>> If we continue adding features without re-design, most of the implementation
>>> might end up in the GroovyPagesTemplateEngine which might not be a good
>>> idea.
>>>
>>> Any ideas about how to add better support for the 2 use cases (dynamic
>>> template engine, usage outside web-request processing)?
>>> Design? Roadmap/Schedule?
>>>
>>> Lari
>>>
>>> ---------------------------------------------------------------------
>>> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Lari Hotari -
Oh yes, you are right, Spring Resource abstraction is similar.

Currently the Resource/ResourceLoader interfaces don't provide the
lastmodified timestamp information directly. That's a problem.

For example, It would be quite hard to add a "StringResource" which also
contains a lastmodified timestamp or create a ResourceLoader that loads
resources from the database while providing information about the
lastmodified timestamp.

It's hard to add expiration/caching logic (GRAILS-5560) without the
lastmodified information.

One possiblity would be to extend the ResourceLoader interface and add
the "long getLastModified(Resource resource)" method to that extended
interface. There should also be ResourceLoader implementation that can
aggregate several ResourceLoaders similar to the one in Freemarker.

In the "dynamic template engine" usecase, I think it would be better to
make users (plugin developers) configure their own separate service bean
instance instead of handling everything in the current
groovyPagesTemplateEngine bean (instance).

Lari


13.01.2011 12:03, Graeme Rocher wrote:

> Well the idea of using the Spring Resource abstraction was to allow you to load from different a database, CMS etc.
>
> The Resource API abstracts the source of the resource and you should be able to specify a different resource loader.
>
> For example at the moment we using GroovyPagesResourceLoader I believe
>
> Cheers
> Graeme
>
> On 13 Jan 2011, at 10:56, Lari Hotari wrote:
>
>> Could we separate the different concerns even more?
>>
>> http://jira.codehaus.org/browse/GRAILS-5560 has a request for adding
>> "lastmodifed" parameter to the GroovyPagesTemplateEngine createTemplate
>> method. Would it make sense to separate template loading?
>>
>> Something similar to the Freemarker TemplateLoader would be nice:
>> http://freemarker.sourceforge.net/docs/api/freemarker/cache/TemplateLoader.html
>> http://freemarker.sourceforge.net/docs/pgui_config_templateloading.html#autoid_38
>> In Freemarker it's easy to implement a TemplateLoader which loads
>> templates from a database , CMS etc..
>>
>> Do we need something like this for GSPs (to better support the use as a
>> dynamic template engine)?
>>
>> Lari
>>
>>
>> 13.01.2011 11:43, Graeme Rocher wrote:
>>> This would have to go into a next major release (earliest being 1.4)
>>>
>>> I would suggestion that GroovyPagesTemplateEngine is a bit too low
>>> level and what we need is a new high-level API that provides methods
>>> to easily render templates. Example:
>>>
>>> interface GroovyPagesService {
>>>           void renderTemplate(String templateText, Writer target)
>>>           void renderTemplate(Reader templateText, Writer target)
>>>           void renderTemplate(URI location, Writer target)
>>>           void renderTemplate(String controller, String template, Writer target)
>>> }
>>>
>>> You could have variations of the API for modified checks etc.
>>>
>>> The tricky thing is going to be handling the caching etc. without
>>> leaking permgen.
>>>
>>> Cheers
>>>
>>>
>>> On Thu, Jan 13, 2011 at 10:34 AM, Lari Hotari<[hidden email]>   wrote:
>>>> Dear Grails devs,
>>>>
>>>> There are several issues open to add better support for using GSPs for these
>>>> use cases:
>>>> * dynamic template engine (templates loaded from database / cms, templates
>>>> editable)
>>>> * usage as template engine outside the web-request processing (templates
>>>> from static gsp files, but rendering done in a background job)
>>>> Currently only the usage as Grails view layer "rendering engine" is properly
>>>> supported.
>>>>
>>>> Correct usage as a dynamic template engine or outside web-request processing
>>>> aren't even documented in the Grails Manual.
>>>>
>>>> Some of the Jira issues related to the subject:
>>>> http://jira.codehaus.org/browse/GRAILS-5560
>>>> http://jira.codehaus.org/browse/GRAILS-6809
>>>> http://jira.codehaus.org/browse/GRAILS-3818
>>>>
>>>> There are also different concerns in the solution:
>>>>
>>>> * template parsing/compilation
>>>> * template rendering/execution
>>>> * template/view resolution (DRY lookup logic etc.)
>>>> * template source loading / re-loading/expiration/lastmodified checks
>>>> * template caching
>>>>
>>>> I don't think all usecases&   concerns should be all supported/implemented on
>>>> the same interface or service bean (or even same instance of a service
>>>> bean).
>>>>
>>>> If we continue adding features without re-design, most of the implementation
>>>> might end up in the GroovyPagesTemplateEngine which might not be a good
>>>> idea.
>>>>
>>>> Any ideas about how to add better support for the 2 use cases (dynamic
>>>> template engine, usage outside web-request processing)?
>>>> Design? Roadmap/Schedule?
>>>>
>>>> Lari
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Lari Hotari -

I looked how this is solved in Spring's scripting support and there
happens to be this kind of solution:
http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/scripting/ScriptSource.html
http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/scripting/support/ResourceScriptSource.html

I wonder if we could use these (solves the isModified checking problem
in plain Resource)?

Lari


13.01.2011 14:31, Lari Hotari wrote:

> Oh yes, you are right, Spring Resource abstraction is similar.
>
> Currently the Resource/ResourceLoader interfaces don't provide the
> lastmodified timestamp information directly. That's a problem.
>
> For example, It would be quite hard to add a "StringResource" which
> also contains a lastmodified timestamp or create a ResourceLoader that
> loads resources from the database while providing information about
> the lastmodified timestamp.
>
> It's hard to add expiration/caching logic (GRAILS-5560) without the
> lastmodified information.
>
> One possiblity would be to extend the ResourceLoader interface and add
> the "long getLastModified(Resource resource)" method to that extended
> interface. There should also be ResourceLoader implementation that can
> aggregate several ResourceLoaders similar to the one in Freemarker.
>
> In the "dynamic template engine" usecase, I think it would be better
> to make users (plugin developers) configure their own separate service
> bean instance instead of handling everything in the current
> groovyPagesTemplateEngine bean (instance).
>
> Lari
>
>
> 13.01.2011 12:03, Graeme Rocher wrote:
>> Well the idea of using the Spring Resource abstraction was to allow
>> you to load from different a database, CMS etc.
>>
>> The Resource API abstracts the source of the resource and you should
>> be able to specify a different resource loader.
>>
>> For example at the moment we using GroovyPagesResourceLoader I believe
>>
>> Cheers
>> Graeme
>>
>> On 13 Jan 2011, at 10:56, Lari Hotari wrote:
>>
>>> Could we separate the different concerns even more?
>>>
>>> http://jira.codehaus.org/browse/GRAILS-5560 has a request for adding
>>> "lastmodifed" parameter to the GroovyPagesTemplateEngine createTemplate
>>> method. Would it make sense to separate template loading?
>>>
>>> Something similar to the Freemarker TemplateLoader would be nice:
>>> http://freemarker.sourceforge.net/docs/api/freemarker/cache/TemplateLoader.html 
>>>
>>> http://freemarker.sourceforge.net/docs/pgui_config_templateloading.html#autoid_38 
>>>
>>> In Freemarker it's easy to implement a TemplateLoader which loads
>>> templates from a database , CMS etc..
>>>
>>> Do we need something like this for GSPs (to better support the use as a
>>> dynamic template engine)?
>>>
>>> Lari
>>>
>>>
>>> 13.01.2011 11:43, Graeme Rocher wrote:
>>>> This would have to go into a next major release (earliest being 1.4)
>>>>
>>>> I would suggestion that GroovyPagesTemplateEngine is a bit too low
>>>> level and what we need is a new high-level API that provides methods
>>>> to easily render templates. Example:
>>>>
>>>> interface GroovyPagesService {
>>>>           void renderTemplate(String templateText, Writer target)
>>>>           void renderTemplate(Reader templateText, Writer target)
>>>>           void renderTemplate(URI location, Writer target)
>>>>           void renderTemplate(String controller, String template,
>>>> Writer target)
>>>> }
>>>>
>>>> You could have variations of the API for modified checks etc.
>>>>
>>>> The tricky thing is going to be handling the caching etc. without
>>>> leaking permgen.
>>>>
>>>> Cheers
>>>>
>>>>
>>>> On Thu, Jan 13, 2011 at 10:34 AM, Lari
>>>> Hotari<[hidden email]>   wrote:
>>>>> Dear Grails devs,
>>>>>
>>>>> There are several issues open to add better support for using GSPs
>>>>> for these
>>>>> use cases:
>>>>> * dynamic template engine (templates loaded from database / cms,
>>>>> templates
>>>>> editable)
>>>>> * usage as template engine outside the web-request processing
>>>>> (templates
>>>>> from static gsp files, but rendering done in a background job)
>>>>> Currently only the usage as Grails view layer "rendering engine"
>>>>> is properly
>>>>> supported.
>>>>>
>>>>> Correct usage as a dynamic template engine or outside web-request
>>>>> processing
>>>>> aren't even documented in the Grails Manual.
>>>>>
>>>>> Some of the Jira issues related to the subject:
>>>>> http://jira.codehaus.org/browse/GRAILS-5560
>>>>> http://jira.codehaus.org/browse/GRAILS-6809
>>>>> http://jira.codehaus.org/browse/GRAILS-3818
>>>>>
>>>>> There are also different concerns in the solution:
>>>>>
>>>>> * template parsing/compilation
>>>>> * template rendering/execution
>>>>> * template/view resolution (DRY lookup logic etc.)
>>>>> * template source loading / re-loading/expiration/lastmodified checks
>>>>> * template caching
>>>>>
>>>>> I don't think all usecases&   concerns should be all
>>>>> supported/implemented on
>>>>> the same interface or service bean (or even same instance of a
>>>>> service
>>>>> bean).
>>>>>
>>>>> If we continue adding features without re-design, most of the
>>>>> implementation
>>>>> might end up in the GroovyPagesTemplateEngine which might not be a
>>>>> good
>>>>> idea.
>>>>>
>>>>> Any ideas about how to add better support for the 2 use cases
>>>>> (dynamic
>>>>> template engine, usage outside web-request processing)?
>>>>> Design? Roadmap/Schedule?
>>>>>
>>>>> Lari
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

Graeme Rocher
Administrator
Seems reasonable

Cheers
Graeme

On 13 Jan 2011, at 17:11, Lari Hotari wrote:

>
> I looked how this is solved in Spring's scripting support and there
> happens to be this kind of solution:
> http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/scripting/ScriptSource.html
> http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/scripting/support/ResourceScriptSource.html
>
> I wonder if we could use these (solves the isModified checking problem
> in plain Resource)?
>
> Lari
>
>
> 13.01.2011 14:31, Lari Hotari wrote:
>> Oh yes, you are right, Spring Resource abstraction is similar.
>>
>> Currently the Resource/ResourceLoader interfaces don't provide the
>> lastmodified timestamp information directly. That's a problem.
>>
>> For example, It would be quite hard to add a "StringResource" which
>> also contains a lastmodified timestamp or create a ResourceLoader that
>> loads resources from the database while providing information about
>> the lastmodified timestamp.
>>
>> It's hard to add expiration/caching logic (GRAILS-5560) without the
>> lastmodified information.
>>
>> One possiblity would be to extend the ResourceLoader interface and add
>> the "long getLastModified(Resource resource)" method to that extended
>> interface. There should also be ResourceLoader implementation that can
>> aggregate several ResourceLoaders similar to the one in Freemarker.
>>
>> In the "dynamic template engine" usecase, I think it would be better
>> to make users (plugin developers) configure their own separate service
>> bean instance instead of handling everything in the current
>> groovyPagesTemplateEngine bean (instance).
>>
>> Lari
>>
>>
>> 13.01.2011 12:03, Graeme Rocher wrote:
>>> Well the idea of using the Spring Resource abstraction was to allow
>>> you to load from different a database, CMS etc.
>>>
>>> The Resource API abstracts the source of the resource and you should
>>> be able to specify a different resource loader.
>>>
>>> For example at the moment we using GroovyPagesResourceLoader I believe
>>>
>>> Cheers
>>> Graeme
>>>
>>> On 13 Jan 2011, at 10:56, Lari Hotari wrote:
>>>
>>>> Could we separate the different concerns even more?
>>>>
>>>> http://jira.codehaus.org/browse/GRAILS-5560 has a request for adding
>>>> "lastmodifed" parameter to the GroovyPagesTemplateEngine createTemplate
>>>> method. Would it make sense to separate template loading?
>>>>
>>>> Something similar to the Freemarker TemplateLoader would be nice:
>>>> http://freemarker.sourceforge.net/docs/api/freemarker/cache/TemplateLoader.html 
>>>>
>>>> http://freemarker.sourceforge.net/docs/pgui_config_templateloading.html#autoid_38 
>>>>
>>>> In Freemarker it's easy to implement a TemplateLoader which loads
>>>> templates from a database , CMS etc..
>>>>
>>>> Do we need something like this for GSPs (to better support the use as a
>>>> dynamic template engine)?
>>>>
>>>> Lari
>>>>
>>>>
>>>> 13.01.2011 11:43, Graeme Rocher wrote:
>>>>> This would have to go into a next major release (earliest being 1.4)
>>>>>
>>>>> I would suggestion that GroovyPagesTemplateEngine is a bit too low
>>>>> level and what we need is a new high-level API that provides methods
>>>>> to easily render templates. Example:
>>>>>
>>>>> interface GroovyPagesService {
>>>>>          void renderTemplate(String templateText, Writer target)
>>>>>          void renderTemplate(Reader templateText, Writer target)
>>>>>          void renderTemplate(URI location, Writer target)
>>>>>          void renderTemplate(String controller, String template,
>>>>> Writer target)
>>>>> }
>>>>>
>>>>> You could have variations of the API for modified checks etc.
>>>>>
>>>>> The tricky thing is going to be handling the caching etc. without
>>>>> leaking permgen.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> On Thu, Jan 13, 2011 at 10:34 AM, Lari
>>>>> Hotari<[hidden email]>   wrote:
>>>>>> Dear Grails devs,
>>>>>>
>>>>>> There are several issues open to add better support for using GSPs
>>>>>> for these
>>>>>> use cases:
>>>>>> * dynamic template engine (templates loaded from database / cms,
>>>>>> templates
>>>>>> editable)
>>>>>> * usage as template engine outside the web-request processing
>>>>>> (templates
>>>>>> from static gsp files, but rendering done in a background job)
>>>>>> Currently only the usage as Grails view layer "rendering engine"
>>>>>> is properly
>>>>>> supported.
>>>>>>
>>>>>> Correct usage as a dynamic template engine or outside web-request
>>>>>> processing
>>>>>> aren't even documented in the Grails Manual.
>>>>>>
>>>>>> Some of the Jira issues related to the subject:
>>>>>> http://jira.codehaus.org/browse/GRAILS-5560
>>>>>> http://jira.codehaus.org/browse/GRAILS-6809
>>>>>> http://jira.codehaus.org/browse/GRAILS-3818
>>>>>>
>>>>>> There are also different concerns in the solution:
>>>>>>
>>>>>> * template parsing/compilation
>>>>>> * template rendering/execution
>>>>>> * template/view resolution (DRY lookup logic etc.)
>>>>>> * template source loading / re-loading/expiration/lastmodified checks
>>>>>> * template caching
>>>>>>
>>>>>> I don't think all usecases&   concerns should be all
>>>>>> supported/implemented on
>>>>>> the same interface or service bean (or even same instance of a
>>>>>> service
>>>>>> bean).
>>>>>>
>>>>>> If we continue adding features without re-design, most of the
>>>>>> implementation
>>>>>> might end up in the GroovyPagesTemplateEngine which might not be a
>>>>>> good
>>>>>> idea.
>>>>>>
>>>>>> Any ideas about how to add better support for the 2 use cases
>>>>>> (dynamic
>>>>>> template engine, usage outside web-request processing)?
>>>>>> Design? Roadmap/Schedule?
>>>>>>
>>>>>> Lari
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

ld@ldaley.com
In reply to this post by Graeme Rocher

On 13/01/2011, at 7:43 PM, Graeme Rocher wrote:

> I would suggestion that GroovyPagesTemplateEngine is a bit too low
> level and what we need is a new high-level API that provides methods
> to easily render templates. Example:
>
> interface GroovyPagesService {
>         void renderTemplate(String templateText, Writer target)
>         void renderTemplate(Reader templateText, Writer target)
>         void renderTemplate(URI location, Writer target)
>         void renderTemplate(String controller, String template, Writer target)
> }
>
> You could have variations of the API for modified checks etc.

I'd contend that this is still too low level for the common cases. Where possible this should be as compatible as possible with the existing render() idioms.

I'd also avoid the use of “Service” as that's already a loaded term.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GroovyPagesTemplateEngine / GSP related re-design needed?

ligongx
In reply to this post by Lari Hotari -
Any decision/recommendation on the dynamic template caching issue? createTemplate(String txt, String pageName) never attempts to use pageCache even though metaInfo is put to pageCache in buildPageMetaInfo() call, while createTemplate(Resource) call does use the pageCache  put and get. I am using dynamic template from db to build a cms system. Should I do the template caching in my application, or grails will provide caching for dynamic template  eventually ?

I read jira GRAILS-5560, and not clear about what application developers should do with caching issue associated with createTemplate(txt, pageName) call.  Thanks for clarification.

-Ligong