|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
Advice / best practice for using Grails view technologies correctlyHello,
I very often face a situation that causes me troubles. I basically wish to render pages that will have a common layout, and only their general content will differ. One could think Sitemesh should be used for writing the layout, and the content of the pages should be broken into various GSP views. The problem is that it is hard to use Sitemesh because the layout uses objects for rendering, and since the Hibernate session is not active when Sitemesh output is rendered, this makes it *extremely* cumbersome to use Sitemesh, since you have to be really careful for LazyInitialization Hibernate exceptions. A second thing I don't like with Sitemesh is that you have only "one place" that can change, eg the <body> tag. Quite often, my views would have two areas that need to be injected back into the Sitemesh layout, and I cannot do that (someone please prove me wrong if I am). I feel there is room for a big improvement in this area. I'd like to hear people advices about this, because I may be ignoring a convenient way to achieve what I need. But if there is no current way to solve the problems I was outlining, here are my suggestions: * Make the OpenSessionInView interceptor also works when rendering Sitemesh layouts (I think this was already discussed). Note that this may have drawbacks (performance, I dont know), and does not solve the second problem I have; * Develop a tag that basically does the reverse of g.render. g.render is absolutely essential (without it GSP would be really limited), and I really feel the reverse tag is needed. Eg, a tag that tells that the contents of the tag should be included within another page that is to be rendered. We should be able to specify the place where it should be rendered in the parent layout, thus working around Sitemesh limitations that I described (as an added bonus, since the layout would be truely a GSP page, I guess the OpenSessionInView issues would not apply). Something that would like that: <g:renderLayout layout="myLayout.gsp"> <g:include place="myDivIdentifier"> <!-- we should be able to specify the place where this is include via a tag name or tag attribute !--> <p>My interesting content.</p> </g:include> <g:include place="myDivIdentifier2"> <p>Another content that goes into a different place.</p> </g:include> </g:renderLayout> The second solution does not seem too hard - Grails developers, what do you think? Maybe what I want is already possible through a plugin to Grails view technologies (did not look at them, but will do), but, IMHO, this should be part of GSP. Jean-Noel --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Advice / best practice for using Grails view technologies correctlyOn Tue, Jul 22, 2008 at 3:15 PM, Jean-Noël Rivasseau <elvanor@...> wrote:
> Hello, > > I very often face a situation that causes me troubles. I basically > wish to render pages that will have a common layout, and only their > general content will differ. One could think Sitemesh should be used > for writing the layout, and the content of the pages should be broken > into various GSP views. The problem is that it is hard to use Sitemesh > because the layout uses objects for rendering, and since the Hibernate > session is not active when Sitemesh output is rendered, this makes it > *extremely* cumbersome to use Sitemesh, since you have to be really > careful for LazyInitialization Hibernate exceptions. This is a bug that should be fixed. > > A second thing I don't like with Sitemesh is that you have only "one > place" that can change, eg the <body> tag. Quite often, my views would > have two areas that need to be injected back into the Sitemesh layout, > and I cannot do that (someone please prove me wrong if I am). Sitemesh supports this with content blocks http://docs.codehaus.org/display/GRAILS/Content+Blocks > > I feel there is room for a big improvement in this area. I'd like to > hear people advices about this, because I may be ignoring a convenient > way to achieve what I need. But if there is no current way to solve > the problems I was outlining, here are my suggestions: > > * Make the OpenSessionInView interceptor also works when rendering > Sitemesh layouts (I think this was already discussed). Note that this > may have drawbacks (performance, I dont know), and does not solve the > second problem I have; > > * Develop a tag that basically does the reverse of g.render. g.render > is absolutely essential (without it GSP would be really limited), and > I really feel the reverse tag is needed. Eg, a tag that tells that the > contents of the tag should be included within another page that is to > be rendered. We should be able to specify the place where it should be > rendered in the parent layout, thus working around Sitemesh > limitations that I described (as an added bonus, since the layout > would be truely a GSP page, I guess the OpenSessionInView issues would > not apply). > > Something that would like that: > > <g:renderLayout layout="myLayout.gsp"> There is already <g:applyLayout> Cheers > > <g:include place="myDivIdentifier"> <!-- we should be able to specify > the place where this is include via a tag name or tag attribute !--> > <p>My interesting content.</p> > </g:include> > > <g:include place="myDivIdentifier2"> > <p>Another content that goes into a different place.</p> > </g:include> > > </g:renderLayout> > > The second solution does not seem too hard - Grails developers, what > do you think? > > Maybe what I want is already possible through a plugin to Grails view > technologies (did not look at them, but will do), but, IMHO, this > should be part of GSP. > > Jean-Noel > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Graeme Rocher Grails Project Lead G2One, Inc. Chief Technology Officer http://www.g2one.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Advice / best practice for using Grails view technologies correctlyI think this content block feature should be more documented (i.e. grails doc). It was a thing that i searched for a long time, and just found thanks to google.
On Tue, Jul 22, 2008 at 11:38 AM, Graeme Rocher <graeme@...> wrote:
-- Fernando "Takai" http://flickr.com/photos/supeertakai http://fernandotakai.tumblr.com/ http://twitter.com/fernando_takai |
|
|
Re: Advice / best practice for using Grails view technologies correctlyThanks for the prompt reply Graeme.
>> *extremely* cumbersome to use Sitemesh, since you have to be really >> careful for LazyInitialization Hibernate exceptions. > > This is a bug that should be fixed. Yep, was not totally sure if this was considered a bug or not, glad to hear you will fix it :) >Sitemesh supports this with content blocks > http://docs.codehaus.org/display/GRAILS/Content+Blocks Thanks for pointing that out! This is just exactly what I needed. I really think it is very important to include this in the official Grails documentation (there is already http://jira.codehaus.org/browse/GRAILS-2907 open for this) ASAP. Else, lots of people like me will believe it is simply a limitation of Sitemesh (Sitemesh documentation is one of the worst I have seen, I have actually learnt sitemesh only via the Grails docs ;). >> Something that would like that: >> >> <g:renderLayout layout="myLayout.gsp"> > > There is already <g:applyLayout> Yes, but g:applyLayout (which is well documented) has a completely different purpose that what I needed... What I needed was really the content blocks feature. That, coupled to the fix for the OSIV interceptor will fulfill all my needs as far as view technologies are concerned in Grails. Jean-Noel --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free Forum Powered by Nabble | Forum Help |