Extending the _Event system in Grails (Re: was something else I can't remember now)
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Extending the _Event system in Grails (Re: was something else I can't remember now)
by Richard Vowles
::
Rate this Message:
Ok, so since no-one responded to me about their ideal way to solve the problem I am going to propose a solution and if I don't get any "but nay!" comments, I'll go ahead and implement a patch and attach it to a JIRA.
My *suggestion* is this - extend the loadEventsHooks in GrailsBuildEventListener so that it looks for all scripts that *start* with _Events. It processes plain _Events as normal, and when an event is fired it checks to see if there are any _Event_That_Event_Name.groovy scripts anywhere, and if so, loads them in with loadEventScript. I would have sworn there was an event ("CompileEnd") in the _GrailsCompile.groovy, but I can no-longer find it anywhere. It might be worthwhile to pepper more events around, but I think this is the biggie. Thus if people need stuff to load after the compilation, they can create a script called _Events_Compile_End.groovy and that will load the extra event triggers into the namespace. On Fri, Jun 19, 2009 at 11:53 AM, Luke Daley <ld@...> wrote:
-- --- Richard Vowles, Talk to me about development in Grails, Groovy, Java and for the Blackberry ph: +64275467747, linkedin, skype:rvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Luke Daley
::
Rate this Message:
On 22/06/2009, at 12:46 PM, Richard Vowles wrote: > Ok, so since no-one responded to me about their ideal way to solve > the problem I am going to propose a solution and if I don't get any > "but nay!" comments, I'll go ahead and implement a patch and attach > it to a JIRA. > > My *suggestion* is this - extend the loadEventsHooks in > GrailsBuildEventListener so that it looks for all scripts that > *start* with _Events. It processes plain _Events as normal, and when > an event is fired it checks to see if there are any > _Event_That_Event_Name.groovy scripts anywhere, and if so, loads > them in with loadEventScript. > > I would have sworn there was an event ("CompileEnd") in the > _GrailsCompile.groovy, but I can no-longer find it anywhere. It > might be worthwhile to pepper more events around, but I think this > is the biggie. > > Thus if people need stuff to load after the compilation, they can > create a script called _Events_Compile_End.groovy and that will load > the extra event triggers into the namespace. Is there no way to run a compile after the plugin is installed and after that execute the plugin's relevant scripts with the libs and classes from the plugin available? --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Richard Vowles
::
Rate this Message:
I think you are talking about _Install.groovy? I'm not really sure of what the problems are with _Install, but that doesn't solve the problem with general runtime uses where the Events script depends on compiled classes (which will always fail). I could implement a specific solution to this problem for easyb, I'm just trying to implement a generic solution that won't impact on the performance or use of scripts for anyone who doesn't need to use it.
Can _Install not just depend on compile when it is run? On Mon, Jun 22, 2009 at 3:20 PM, Luke Daley <ld@...> wrote:
-- --- Richard Vowles, Talk to me about development in Grails, Groovy, Java and for the Blackberry ph: +64275467747, linkedin, skype:rvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Luke Daley
::
Rate this Message:
On 22/06/2009, at 1:49 PM, Richard Vowles wrote: > I think you are talking about _Install.groovy? I'm not really sure > of what the problems are with _Install, but that doesn't solve the > problem with general runtime uses where the Events script depends on > compiled classes (which will always fail). I could implement a > specific solution to this problem for easyb, I'm just trying to > implement a generic solution that won't impact on the performance or > use of scripts for anyone who doesn't need to use it. Ah yes I am. Why can't the classes be compiled before _Events is? > Can _Install not just depend on compile when it is run? Would that compile the plugin to be installed as well? --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Richard Vowles
::
Rate this Message:
[I am thinking you might be in the same/similar timezone to me?]
On Mon, Jun 22, 2009 at 3:56 PM, Luke Daley <ld@...> wrote:
That would mean that no events could fire before _GrailsCompile.groovy were completed - and that would be a change in behavior that would probably have far reaching consequences and unlikely to pass the powers that be. Can _Install not just depend on compile when it is run? Would that compile the plugin to be installed as well? [I have this feeling you are trying to lead me to a conclusion and I am not getting it] You would be compiling the current project, so yes. But the problem is that when you try and compile a plugin, the plugin distribution prevents files that Grails expects to exist from being included, hence it won't compile (currently). If the Grails compliation mechanism could be changed to recognize it was in a plugin and thus missing those things was OK, then I can't see a problem here. But then you would get items in your ~/.grails/version/projects directory matching each plugin that you install. Not sure this is a bad thing, but it is a thing. IMHO, some changes in Grails compilation are in order because when you store your project in a Git repository, it doesn't version empty directories. If you have nothing in src/java or grails-app/conf/resource then when you check it out it won't compile (for example). But that is a different issue. I'm just trying to get a zero impact change for _Events.groovy implemented so I can finish grails-easyb and grails-easyb-gfunc. :-) Richard -- --- Richard Vowles, Talk to me about development in Grails, Groovy, Java and for the Blackberry ph: +64275467747, linkedin, skype:rvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Luke Daley
::
Rate this Message:
On 22/06/2009, at 2:11 PM, Richard Vowles wrote: [I am thinking you might be in the same/similar timezone to me?] East Coast Australia (Brisbane), so GMT +10.
I am not sure a zero impact change is possible. The current gfunc plugin errors on installation because of this problem. In my opinion you should ship what you have and just advertise that you will get errors on install because of this Grails bug. Then once the version comes out with your patch everything will be great :) Thanks for working on these plugins BTW. I am looking forward to using them. |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Richard Vowles
::
Rate this Message:
On Mon, Jun 22, 2009 at 4:52 PM, Luke Daley <ld@...> wrote:
Maybe we should talk about this on Saturday at citcon? Anyone else from this list going? -- --- Richard Vowles, Talk to me about development in Grails, Groovy, Java and for the Blackberry ph: +64275467747, linkedin, skype:rvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Lee Butts
::
Rate this Message:
I'll be there,
cheers Lee 2009/6/22 Richard Vowles <richard@...>
|
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Luke Daley
::
Rate this Message:
On 22/06/2009, at 2:55 PM, Richard Vowles wrote: > Maybe we should talk about this on Saturday at citcon? Sounds good. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Graeme Rocher-3
::
Rate this Message:
Hi Richard,
_Events.groovy is a script and hence like all other scripts it plays by the same rules in that you don't have access to sources from inside the script unless you explicitly compile and load them. You need to depend on compile() and classpath() and then use the classloader to explicitly load your classes:
myClass = classLoader.loadClass("MyClass") The reason is this is because some events run before compilation happens. You can't have it both ways. As for the missing CompileEnd event, in Grails 1.1 we removed the majority of hard coded events. Now Grails will fire an event whenever it encounters a target. So for: target(name:"compile)
You will get CompileStart and CompileEnd events Cheers On Mon, Jun 22, 2009 at 3:46 AM, Richard Vowles <richard@...> wrote: Ok, so since no-one responded to me about their ideal way to solve the problem I am going to propose a solution and if I don't get any "but nay!" comments, I'll go ahead and implement a patch and attach it to a JIRA. -- Graeme Rocher Head of Grails Development SpringSource - Weapons for the War on Java Complexity http://www.springsource.com |
|
|
Re: Extending the _Event system in Grails (Re: was something else I can't remember now)
by Richard Vowles
::
Rate this Message:
On Mon, Jun 22, 2009 at 7:28 PM, Graeme Rocher <graeme.rocher@...> wrote:
Hi Richard, Hi Graeme - that was why I was suggesting to not have it both ways. I agree, the problem I get is because I depend on classes that haven't been compiled yet, and the _Events.groovy loads at the start of the script running process. Hence, errors - the classes aren't compiled yet - the problem is with the way _Events.groovy is used. My suggestion is to introduce a naming convention to allow the *delay* of loading some event based scripts until a specific event fires. The GrailsBuildEventListener will find the files (all starting with _Event) but not load them until the named event fires (e.g. compile ends, the event CompileEnd fires, the GrailsBuildEventLIstener will look for any previously found files called _Event_CompileEnd.groovy and then load them with the current class loader, by which time the classes should exist). The effect as far as I can ascertain (but without actually doing it) is that it would have no side-effects and would be a clean solution to this particular issue. You may know that it can't be done and I'll run into all sorts of difficulty :-) I realize that I could code my events using loadClass("full pathname to class") which would in this release (and previous releases) get around this problem, but it makes the events messy and hard to maintain. I will however be doing this so I get around the double compile problem, especially if the easyb stuff is to be useful to people now. This suggested fix is not necessary, but it would be nice. I will probably code it up in any case as I am already patching some of my scripts (the GrailsTest JIRA for example which allows all unit/integration/functional tests to be run in one go without having to run three different command line requests), and just attach it as a JIRA. Richard -- --- Richard Vowles, Talk to me about development in Grails, Groovy, Java and for the Blackberry ph: +64275467747, linkedin, skype:rvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com |
|
|
Proposed change to g:render
by nycsailor
::
Rate this Message:
I frequently want to use the g.render tag with a body. Currently I must
create a taglib entry and place the body in a attribute that is passed to g.render. Why not make this the default behavior of g.render? Looking at the code for g.render it looks like adding attrs.body = body() would do the trick. Of course in the rendered template you can then just add ${body} wherever you want the body or we can create a tag that renders the body (like <g:renderBody>). What do people think? Should this be added to g.render tag or make a separate tag for this? Anyone have a better idea? Scott --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by Jeff Brown-14
::
Rate this Message:
On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote:
> I frequently want to use the g.render tag with a body. Currently I must > create a taglib entry and place the body in a attribute that is passed > to g.render. > > Why not make this the default behavior of g.render? Looking at the code > for g.render it looks like adding attrs.body = body() would do the > trick. Of course in the rendered template you can then just add ${body} > wherever you want the body or we can create a tag that renders the body > (like <g:renderBody>). > > What do people think? Should this be added to g.render tag or make a > separate tag for this? Anyone have a better idea? > > Scott > > Can you show a simple use case that justifies the feature? Thanks for the help. Jeff -- Jeff Brown SpringSource 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 |
|
|
Re: Proposed change to g:render
by Drew Varner
::
Rate this Message:
When I first read this, I thought it read "Proposed change to gender",
kind of off topic for the dev list. Now, I see it's more relevant than I thought. - Drew On Jun 24, 2009, at 7:29 PM, Jeff Brown wrote: > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> > wrote: >> I frequently want to use the g.render tag with a body. Currently I >> must >> create a taglib entry and place the body in a attribute that is >> passed >> to g.render. >> >> Why not make this the default behavior of g.render? Looking at the >> code >> for g.render it looks like adding attrs.body = body() would do the >> trick. Of course in the rendered template you can then just add $ >> {body} >> wherever you want the body or we can create a tag that renders the >> body >> (like <g:renderBody>). >> >> What do people think? Should this be added to g.render tag or make a >> separate tag for this? Anyone have a better idea? >> >> Scott >> >> > > Can you show a simple use case that justifies the feature? > > Thanks for the help. > > > > > Jeff > > -- > Jeff Brown > SpringSource > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
Absolutely.
I'm happy to. Pardon any typos in the following, I'm just making it up. Say I want to create a block with some smaller things in it and some amount of larger things. For a very simple example say there is a block with a title. Here is how I do it now. SomethingTagLib ---------------- def titleBlock = {attrs, body out << g.render(template:'titleBlock', model:[title:attrs.title, body:body()] } _titleBlock.gsp ---------------- <div class=block> <h1>${title}</h1> <div class='blockBody'>${body}</div> </div> some.gsp --------------------- <g:titleBlock title='title'> Body stuff here </g:titleBlock> Of course the body could be passed as an attribute, but that could be messy with large bodies and where you want to use tags in the body. It could also be done with <g:set> but again that is a bit messy <g:set var='blockBody'> --- block body stuff --- </g:set> <g:render template='titleBlock' model="[title:'some title', body:blockBody]" /> If you need any additional info please let me know, but this is something I run into very frequently. I have not looked deeply into the code, but it seems that this would be possible by adding it to the model being rendered much like I do in the taglib. On Wed, 2009-06-24 at 11:29 -0400, Jeff Brown wrote: > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote: > > I frequently want to use the g.render tag with a body. Currently I must > > create a taglib entry and place the body in a attribute that is passed > > to g.render. > > > > Why not make this the default behavior of g.render? Looking at the code > > for g.render it looks like adding attrs.body = body() would do the > > trick. Of course in the rendered template you can then just add ${body} > > wherever you want the body or we can create a tag that renders the body > > (like <g:renderBody>). > > > > What do people think? Should this be added to g.render tag or make a > > separate tag for this? Anyone have a better idea? > > > > Scott > > > > > > Can you show a simple use case that justifies the feature? > > Thanks for the help. > > > > > Jeff > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
Maybe to put it better. It is a hybrid between applyLayout and render
with features of both. On Wed, 2009-06-24 at 11:29 -0400, Jeff Brown wrote: > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote: > > I frequently want to use the g.render tag with a body. Currently I must > > create a taglib entry and place the body in a attribute that is passed > > to g.render. > > > > Why not make this the default behavior of g.render? Looking at the code > > for g.render it looks like adding attrs.body = body() would do the > > trick. Of course in the rendered template you can then just add ${body} > > wherever you want the body or we can create a tag that renders the body > > (like <g:renderBody>). > > > > What do people think? Should this be added to g.render tag or make a > > separate tag for this? Anyone have a better idea? > > > > Scott > > > > > > Can you show a simple use case that justifies the feature? > > Thanks for the help. > > > > > Jeff > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
Just for fun, I took the original code and modified it for g.render to make this behavior happen.
I have not fully tested it, but here it is working at least with templates and models. Mainly I pulled def b out of each of the if statements. I then inserted body into the Map b I then made sure that b is always passed to t.make I think we should probably change the key from 'body' to something like 'renderBody' and we should make a tag that renders the body like <g:renderBody> What does everyone else think?
def render = { attrs, body ->
if(!groovyPagesTemplateEngine) throw new IllegalStateException("Property [groovyPagesTemplateEngine] must be set!")
if(!attrs.template)
throwTagError("Tag [render] is missing required attribute [template]")
def engine = groovyPagesTemplateEngine
def uri = grailsAttributes.getTemplateUri(attrs.template,request)
def var = attrs['var']
def contextPath = attrs.contextPath ? attrs.contextPath : ""
if(attrs.plugin) {
def plugin = pluginManager?.getGrailsPlugin(attrs.plugin)
if(plugin && !plugin.isBasePlugin()) contextPath = plugin.getPluginPath()
}
Template t
if(TEMPLATE_CACHE.containsKey(uri) && !engine.isReloadEnabled()) {
t = TEMPLATE_CACHE[uri]
}
else {
def r = engine.getResourceForUri("${contextPath}${uri}")
if(!r.exists()) r = engine.getResourceForUri("${contextPath}/grails-app/views/${uri}")
t = engine.createTemplate( r )
TEMPLATE_CACHE[uri] = t
}
def b = [body:body ? body() : '']
if(attrs.containsKey('bean')) {
if (attrs.model instanceof Map) {
b += attrs.model
}
if (var) {
b.put(var, attrs.bean)
}
else {
b.put('it', attrs.bean)
}
t.make(b).writeTo(out)
}
else if(attrs.containsKey('collection')) {
def collection = attrs.collection
def key = 'it'
if(collection) {
def first = collection.iterator().next()
key = first ? GrailsNameUtils.getPropertyName(first.getClass()) : 'it'
}
collection.each {
if (attrs.model instanceof Map) {
b += attrs.model
}
if (var) {
b.put(var, it)
}
else {
b.put('it', it)
b.put(key, it)
}
t.make(b).writeTo(out)
}
}
else if(attrs.model instanceof Map) {
t.make( b + attrs.model ).writeTo(out)
}
else if(attrs.template) {
t.make(b).writeTo(out)
}
}
On Wed, 2009-06-24 at 12:02 -0400, Scott Burch wrote: Maybe to put it better. It is a hybrid between applyLayout and render with features of both. On Wed, 2009-06-24 at 11:29 -0400, Jeff Brown wrote: > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote: > > I frequently want to use the g.render tag with a body. Currently I must > > create a taglib entry and place the body in a attribute that is passed > > to g.render. > > > > Why not make this the default behavior of g.render? Looking at the code > > for g.render it looks like adding attrs.body = body() would do the > > trick. Of course in the rendered template you can then just add ${body} > > wherever you want the body or we can create a tag that renders the body > > (like <g:renderBody>). > > > > What do people think? Should this be added to g.render tag or make a > > separate tag for this? Anyone have a better idea? > > > > Scott > > > > > > Can you show a simple use case that justifies the feature? > > Thanks for the help. > > > > > Jeff > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
To take this one step further, maybe create a new tag that passes on the
attributes and the body, so you can have. <g:renderWithBody template='block' title='some title'> block contents here </g:renderWithBody> And render with body can have access to title _renderWithBody.gsp ------------------------ <div class='block'> <h1>${title}</h1> <div class='blockBody'><g:renderBody /></div> </div> Or am I going too far? Am I missing functionality that already exists? Seems like applyLayout should do this, but it either takes a body or a template with no body, it does not take a template AND a body. On Wed, 2009-06-24 at 14:06 -0400, Scott Burch wrote: > Just for fun, I took the original code and modified it for g.render to > make this behavior happen. > > I have not fully tested it, but here it is working at least with > templates and models. > > Mainly I pulled def b out of each of the if statements. > I then inserted body into the Map b > I then made sure that b is always passed to t.make > > I think we should probably change the key from 'body' to something > like 'renderBody' and we should make a tag that renders the body like > <g:renderBody> > > What does everyone else think? > > > > def render = { attrs, body -> > if(!groovyPagesTemplateEngine) throw new IllegalStateException("Property [groovyPagesTemplateEngine] must be set!") > if(!attrs.template) > throwTagError("Tag [render] is missing required attribute [template]") > > def engine = groovyPagesTemplateEngine > def uri = grailsAttributes.getTemplateUri(attrs.template,request) > def var = attrs['var'] > def contextPath = attrs.contextPath ? attrs.contextPath : "" > > if(attrs.plugin) { > def plugin = pluginManager?.getGrailsPlugin(attrs.plugin) > if(plugin && !plugin.isBasePlugin()) contextPath = plugin.getPluginPath() > } > > Template t > if(TEMPLATE_CACHE.containsKey(uri) && !engine.isReloadEnabled()) { > t = TEMPLATE_CACHE[uri] > } > else { > def r = engine.getResourceForUri("${contextPath}${uri}") > if(!r.exists()) r = engine.getResourceForUri("${contextPath}/grails-app/views/${uri}") > t = engine.createTemplate( r ) > TEMPLATE_CACHE[uri] = t > } > > def b = [body:body ? body() : ''] > > if(attrs.containsKey('bean')) { > if (attrs.model instanceof Map) { > b += attrs.model > } > if (var) { > b.put(var, attrs.bean) > } > else { > b.put('it', attrs.bean) > } > t.make(b).writeTo(out) > } > else if(attrs.containsKey('collection')) { > def collection = attrs.collection > def key = 'it' > if(collection) { > def first = collection.iterator().next() > key = first ? GrailsNameUtils.getPropertyName(first.getClass()) : 'it' > } > collection.each { > if (attrs.model instanceof Map) { > b += attrs.model > } > if (var) { > b.put(var, it) > } > else { > b.put('it', it) > b.put(key, it) > } > t.make(b).writeTo(out) > } > } > else if(attrs.model instanceof Map) { > t.make( b + attrs.model ).writeTo(out) > } > else if(attrs.template) { > t.make(b).writeTo(out) > } > } > > > On Wed, 2009-06-24 at 12:02 -0400, Scott Burch wrote: > > Maybe to put it better. It is a hybrid between applyLayout and render > > with features of both. > > > > On Wed, 2009-06-24 at 11:29 -0400, Jeff Brown wrote: > > > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote: > > > > I frequently want to use the g.render tag with a body. Currently I must > > > > create a taglib entry and place the body in a attribute that is passed > > > > to g.render. > > > > > > > > Why not make this the default behavior of g.render? Looking at the code > > > > for g.render it looks like adding attrs.body = body() would do the > > > > trick. Of course in the rendered template you can then just add ${body} > > > > wherever you want the body or we can create a tag that renders the body > > > > (like <g:renderBody>). > > > > > > > > What do people think? Should this be added to g.render tag or make a > > > > separate tag for this? Anyone have a better idea? > > > > > > > > Scott > > > > > > > > > > > > > > Can you show a simple use case that justifies the feature? > > > > > > Thanks for the help. > > > > > > > > > > > > > > > Jeff > > > > > > > > > --------------------------------------------------------------------- > > 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 |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
Sorry, that was supposed to be _block.gsp not _renderWithBody.gsp
On Wed, 2009-06-24 at 14:33 -0400, Scott Burch wrote: > To take this one step further, maybe create a new tag that passes on the > attributes and the body, so you can have. > > <g:renderWithBody template='block' title='some title'> > block contents here > </g:renderWithBody> > > And render with body can have access to title > > _renderWithBody.gsp > ------------------------ > > <div class='block'> > <h1>${title}</h1> > <div class='blockBody'><g:renderBody /></div> > </div> > > Or am I going too far? Am I missing functionality that already exists? > Seems like applyLayout should do this, but it either takes a body or a > template with no body, it does not take a template AND a body. > > > > On Wed, 2009-06-24 at 14:06 -0400, Scott Burch wrote: > > Just for fun, I took the original code and modified it for g.render to > > make this behavior happen. > > > > I have not fully tested it, but here it is working at least with > > templates and models. > > > > Mainly I pulled def b out of each of the if statements. > > I then inserted body into the Map b > > I then made sure that b is always passed to t.make > > > > I think we should probably change the key from 'body' to something > > like 'renderBody' and we should make a tag that renders the body like > > <g:renderBody> > > > > What does everyone else think? > > > > > > > > def render = { attrs, body -> > > if(!groovyPagesTemplateEngine) throw new IllegalStateException("Property [groovyPagesTemplateEngine] must be set!") > > if(!attrs.template) > > throwTagError("Tag [render] is missing required attribute [template]") > > > > def engine = groovyPagesTemplateEngine > > def uri = grailsAttributes.getTemplateUri(attrs.template,request) > > def var = attrs['var'] > > def contextPath = attrs.contextPath ? attrs.contextPath : "" > > > > if(attrs.plugin) { > > def plugin = pluginManager?.getGrailsPlugin(attrs.plugin) > > if(plugin && !plugin.isBasePlugin()) contextPath = plugin.getPluginPath() > > } > > > > Template t > > if(TEMPLATE_CACHE.containsKey(uri) && !engine.isReloadEnabled()) { > > t = TEMPLATE_CACHE[uri] > > } > > else { > > def r = engine.getResourceForUri("${contextPath}${uri}") > > if(!r.exists()) r = engine.getResourceForUri("${contextPath}/grails-app/views/${uri}") > > t = engine.createTemplate( r ) > > TEMPLATE_CACHE[uri] = t > > } > > > > def b = [body:body ? body() : ''] > > > > if(attrs.containsKey('bean')) { > > if (attrs.model instanceof Map) { > > b += attrs.model > > } > > if (var) { > > b.put(var, attrs.bean) > > } > > else { > > b.put('it', attrs.bean) > > } > > t.make(b).writeTo(out) > > } > > else if(attrs.containsKey('collection')) { > > def collection = attrs.collection > > def key = 'it' > > if(collection) { > > def first = collection.iterator().next() > > key = first ? GrailsNameUtils.getPropertyName(first.getClass()) : 'it' > > } > > collection.each { > > if (attrs.model instanceof Map) { > > b += attrs.model > > } > > if (var) { > > b.put(var, it) > > } > > else { > > b.put('it', it) > > b.put(key, it) > > } > > t.make(b).writeTo(out) > > } > > } > > else if(attrs.model instanceof Map) { > > t.make( b + attrs.model ).writeTo(out) > > } > > else if(attrs.template) { > > t.make(b).writeTo(out) > > } > > } > > > > > > On Wed, 2009-06-24 at 12:02 -0400, Scott Burch wrote: > > > Maybe to put it better. It is a hybrid between applyLayout and render > > > with features of both. > > > > > > On Wed, 2009-06-24 at 11:29 -0400, Jeff Brown wrote: > > > > On Wed, Jun 24, 2009 at 11:00 AM, Scott Burch<scott@...> wrote: > > > > > I frequently want to use the g.render tag with a body. Currently I must > > > > > create a taglib entry and place the body in a attribute that is passed > > > > > to g.render. > > > > > > > > > > Why not make this the default behavior of g.render? Looking at the code > > > > > for g.render it looks like adding attrs.body = body() would do the > > > > > trick. Of course in the rendered template you can then just add ${body} > > > > > wherever you want the body or we can create a tag that renders the body > > > > > (like <g:renderBody>). > > > > > > > > > > What do people think? Should this be added to g.render tag or make a > > > > > separate tag for this? Anyone have a better idea? > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > Can you show a simple use case that justifies the feature? > > > > > > > > Thanks for the help. > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Proposed change to g:render
by nycsailor
::
Rate this Message:
Sorry about all of the messages, trying to provide as much info as possible.
I modified the render closure to add the attributes to the map and I can now share the full solution from code I am doing right now. >From my gsp file. -----------------------
<sws:render template="block" title="Recent Blog Entries" titleLinkText="view all" titleLinkUrl="${createLink(url:[controller:'node', action:'showAll', type:'standardNode'])}">
<cms:nodeSummary />
</sws:render>
<sws:render template="block" title="Blog Archive">
<cms:nodeArchive />
</sws:render>
_block.gsp --------------- <div class="block"> <div class="title"> <g:if test="${titleLinkText}"> <span class="titleLink"> (<a href="${titleLinkUrl}">${titleLinkText}</a>) </span> </g:if> <span>${title}</span> </div> <div class="body">${body}</div> </div> New maybe hacky render code ----------------------------
def render = { attrs, body ->
if(!groovyPagesTemplateEngine) throw new IllegalStateException("Property [groovyPagesTemplateEngine] must be set!")
if(!attrs.template)
throwTagError("Tag [render] is missing required attribute [template]")
def engine = groovyPagesTemplateEngine
def uri = grailsAttributes.getTemplateUri(attrs.template,request)
def var = attrs['var']
def contextPath = attrs.contextPath ? attrs.contextPath : ""
if(attrs.plugin) {
def plugin = pluginManager?.getGrailsPlugin(attrs.plugin)
if(plugin && !plugin.isBasePlugin()) contextPath = plugin.getPluginPath()
}
Template t
if(TEMPLATE_CACHE.containsKey(uri) && !engine.isReloadEnabled()) {
t = TEMPLATE_CACHE[uri]
}
else {
def r = engine.getResourceForUri("${contextPath}${uri}")
if(!r.exists()) r = engine.getResourceForUri("${contextPath}/grails-app/views/${uri}")
t = engine.createTemplate( r )
TEMPLATE_CACHE[uri] = t
}
// temporarily I just added the attrs map to the map that will be passed to t.make()
def b = [body:body ? body() : ''] + attrs
if(attrs.containsKey('bean')) {
if (attrs.model instanceof Map) {
b += attrs.model
}
if (var) {
b.put(var, attrs.bean)
}
else {
b.put('it', attrs.bean)
}
t.make(b).writeTo(out)
}
else if(attrs.containsKey('collection')) {
def collection = attrs.collection
def key = 'it'
if(collection) {
def first = collection.iterator().next()
key = first ? GrailsNameUtils.getPropertyName(first.getClass()) : 'it'
}
collection.each {
if (attrs.model instanceof Map) {
b += attrs.model
}
if (var) {
b.put(var, it)
}
else {
b.put('it', it)
b.put(key, it)
}
t.make(b).writeTo(out)
}
}
else if(attrs.model instanceof Map) {
t.make( b + attrs.model ).writeTo(out)
}
else if(attrs.template) {
t.make(b).writeTo(out)
}
}
On Wed, 2009-06-24 at 14:39 -0400, Scott Burch wrote:
|
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
