gsp taglib pull request

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

gsp taglib pull request

houbie
Hi,

Please consider the  gsp taglib pull request for integration into the grails core. This will make it possible to create tags from gsp snippets (see http://grails.org/plugin/gsp-taglib)

The gsp's are translated into a groovy taglib in 'target/generated-sources/grails-app/taglib'. The GroovyPagesGrailsPlugin has been modified to automatically pick up changes.

Grtz,
Ivo
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

smaldini
I'm voting 0 as :
  • the plugin already does the job quite well 
  • there is the tmpl namespace
  • Dependency injection makes page looks like scriptlet soup
  • I plan to refactor gsp binding, so more to maintain doesn't appeal me :p

But that's my point of view and I can see the benefit of avoiding a middle-taglib just to call namespaced view behinds. 

On Wed, Mar 28, 2012 at 1:32 PM, houbie <[hidden email]> wrote:
Hi,

Please consider the  https://github.com/grails/grails-core/pull/175  gsp
taglib pull request  for integration into the grails core. This will make it
possible to create tags from gsp snippets (see
http://grails.org/plugin/gsp-taglib)

The gsp's are translated into a groovy taglib in
'target/generated-sources/grails-app/taglib'. The GroovyPagesGrailsPlugin
has been modified to automatically pick up changes.

Grtz,
Ivo

--
View this message in context: http://grails.1312388.n4.nabble.com/gsp-taglib-pull-request-tp4512023p4512023.html
Sent from the Grails - dev mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email





--
Stéphane MALDINI
--


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

houbie
   - the plugin already does the job quite well
The major problem with the plugin is the fact that the generated code ends up between the regular code in your VCS
   - there is the tmpl namespace
The tmpl namespace is not suited for creating UI components because:
- tags are much faster then templates
- tags come with an API, docs and code completion
- gsp tags are placed in the taglib dir where they belong, not in the views dir
   - Dependency injection makes page looks like scriptlet soup
This hack has been removed. Instead I created the new inject tag.
   - I plan to refactor gsp binding, so more to maintain doesn't appeal me
I don't see how this is affected by gsp binding, or do you intend to refactor the GroovyPageParser?
In that case the GspTagParser can only become much simpler and I would be glad to refactor it accordingly :)

Grtz,
Ivo
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

johnrengelman
Is there an example usage somewhere?

On Wed, Mar 28, 2012 at 7:15 AM, houbie <[hidden email]> wrote:


>    - the plugin already does the job quite well
>
The major problem with the plugin is the fact that the generated code ends
up between the regular code in your VCS


>    - there is the tmpl namespace
>
The tmpl namespace is not suited for creating UI components because:
- tags are much faster then templates
- tags come with an API, docs and code completion
- gsp tags are placed in the taglib dir where they belong, not in the views
dir


>    - Dependency injection makes page looks like scriptlet soup
>
This hack has been removed. Instead I created the new inject tag.


>    - I plan to refactor gsp binding, so more to maintain doesn't appeal me
>
I don't see how this is affected by gsp binding, or do you intend to
refactor the GroovyPageParser?
In that case the GspTagParser can only become much simpler and I would be
glad to refactor it accordingly :)

Grtz,
Ivo

--
View this message in context: http://grails.1312388.n4.nabble.com/gsp-taglib-pull-request-tp4512023p4512102.html
Sent from the Grails - dev mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Marc Palmer Local
In reply to this post by houbie

On 28 Mar 2012, at 12:32, houbie wrote:

> Hi,
>
> Please consider the  https://github.com/grails/grails-core/pull/175  gsp
> taglib pull request  for integration into the grails core. This will make it
> possible to create tags from gsp snippets (see
> http://grails.org/plugin/gsp-taglib)
>
> The gsp's are translated into a groovy taglib in
> 'target/generated-sources/grails-app/taglib'. The GroovyPagesGrailsPlugin
> has been modified to automatically pick up changes.
>
>

Hi Ivo,

I'm afraid I'm going to -1 this.

My rationale:

1) It is IMO not a significant improvement over using g:render in a tag currently
2) Having all such code coming out of a non-generated TagLib you write gives better visibility - for docs, IDEs etc
3) It introduces "yet another way to do it" which, re: (1) is for truly marginal gain
4) It is not suitable for all taglibs either - it is for the subset of primarily markup output tags with little logic. If there is logic you descend into lots of <g:if> or inline groovy which are neither good solutions for such.

Can I ask what is your core rational for this - what makes this feature attractive to you vs writing a TagLib that calls g:render.

I prefer g:render because it is very clear what is happening, you can populate the model of the template with just what you need, injection is clear etc.

Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java/UX)

I offer commercial support for Grails plugins from as low as $50/mo.
For details see: http://grailsrocks.com

Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
Contributor @ http://grails.org |  Founder @ http://noticelocal.com
Developer @ http://weceem.org | Member @ http://spottymushroom.com
Twitter: http://twitter.com/wangjammer5 


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

houbie
In reply to this post by johnrengelman
johnrengelman wrote
Is there an example usage somewhere?
see http://grails.org/plugin/gsp-taglib, but in its simplest form it is just a piece of any gsp
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

houbie
In reply to this post by Marc Palmer Local
1) It is IMO not a significant improvement over using g:render in a tag currently
As pointed out earlier the g:render and tmpl namespace are not suited for creating UI components because:
- tags are much faster then templates
- tags come with an API, docs and code completion
- gsp tags are placed in the taglib dir where they belong, not in the views dir
- using g:render, you need to define 2 things: the template and the tag that renders it
2) Having all such code coming out of a non-generated TagLib you write gives better visibility - for docs, IDEs etc
Currently I already get navigation, syntax coloring and code completion both when writing the tags and when using them. But most important, typical UI components that contain more markup then logic, are far more easier to write and to read in a gsp
3) It introduces "yet another way to do it" which, re: (1) is for truly marginal gain
4) It is not suitable for all taglibs either - it is for the subset of primarily markup output tags with little logic. If there is logic you descend into lots of <g:if> or inline groovy which are neither good solutions for such.
Just lik JSP and JSF have two ways of defining tags; in java or in JSP/facelet. The ratio logic/markup determines the choice
Can I ask what is your core rational for this - what makes this feature attractive to you vs writing a TagLib that calls g:render.
Except for the above reasons, there is also marketing value: when my colleagues tell about how easy you can create tags in JSP/JSF from a page snippet, I just want to reply grails can do that :)
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Marc Palmer Local

On 28 Mar 2012, at 14:05, houbie wrote:

>
>
>> 1) It is IMO not a significant improvement over using g:render in a tag
>> currently
>>
> As pointed out earlier the g:render and tmpl namespace are not suited for
> creating UI components because:
> - tags are much faster then templates

Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?

The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?

> - tags come with an API, docs and code completion

There is no difference here to a tag that calls g:render.

> - gsp tags are placed in the taglib dir where they belong, not in the views
> dir

Again this is a non-issue IMO. Its clear what a grails-app/views/_tags folder would be for.

> - using g:render, you need to define 2 things: the template and the tag that
> renders it
>

Yes, and that works within established mechanisms very well.

There is just one way to write tags. That has value.

>
>> 2) Having all such code coming out of a non-generated TagLib you write
>> gives better visibility - for docs, IDEs etc
>>
> Currently I already get navigation, syntax coloring and code completion both
> when writing the tags and when using them. But most important, typical UI
> components that contain more markup then logic, are far more easier to write
> and to read in a gsp
>

How do you get that completion? Surely it is only possible in an IDE after your generated sources have been compiled by the IDE?

>
>> 3) It introduces "yet another way to do it" which, re: (1) is for truly
>> marginal gain
>> 4) It is not suitable for all taglibs either - it is for the subset of
>> primarily markup output tags with little logic. If there is logic you
>> descend into lots of <g:if> or inline groovy which are neither good
>> solutions for such.
>>
> Just lik JSP and JSF have two ways of defining tags; in java or in
> JSP/facelet. The ratio logic/markup determines the choice
>

I would never suggest JSP or JSF as a sound model for concepts :)

Just because they do something, it does not make it good.

They also have inline Java support, which (sadly) we carried over to GSP too for inline Groovy code.

>
>> Can I ask what is your core rational for this - what makes this feature
>> attractive to you vs writing a TagLib that calls g:render.
>>
> Except for the above reasons, there is also marketing value: when my
> colleagues tell about how easy you can create tags in JSP/JSF from a page
> snippet, I just want to reply /grails can do that/ :)


It can:

class MyTagLib {
    def myTag = { attrs ->
       out << g.render(template:'/views/_tags/myTag', model:[attrs:attrs])
    }
}

Also note that type safety and checking of attribute values etc is best done in real TagLib code. Otherwise you are doing a lot of Groovy code in a GSP which is bad.

I still vote -1, this should remain in a plugin. If more hooks are needed to help it integrate better, add the hooks, but IMO don't add this feature to core.

Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java/UX)

I offer commercial support for Grails plugins from as low as $50/mo.
For details see: http://grailsrocks.com

Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
Contributor @ http://grails.org |  Founder @ http://noticelocal.com
Developer @ http://weceem.org | Member @ http://spottymushroom.com
Twitter: http://twitter.com/wangjammer5 


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

houbie
>> - tags are much faster then templates
>
> Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?
>
> The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?

When rendering a template, a page context needs to be constructed. This is not the case when calling a tag.
In my current project, we have about 50 UI components that where first build using a tag + template. Since most tags call other tags that call other tags... we got hundreds of templates rendered per page making everything slow. Migrating to gsp tags fixed the performance issue.

>
>> - tags come with an API, docs and code completion
>
> There is no difference here to a tag that calls g:render.
When I type "<c:box" , Intellij already adds the required attributes and has completion for the optional ones. When I type "<g:render", it doesn't have a clue about what's in the model.
Which would you prefer:
<c:box titleCode="my.title">...</c:box>
or
<g:render template="box" model="${titleCode: 'my.title}">...</g:template>

I guess this is the reason why grails has both tags and templates :)

>
>> - gsp tags are placed in the taglib dir where they belong, not in the views
>> dir
>
> Again this is a non-issue IMO. Its clear what a grails-app/views/_tags folder would be for.
You can easily navigate from a tag to its corresponding template, but not back. With more then 50 components this is not exactly convenient :(

>
>> - using g:render, you need to define 2 things: the template and the tag that
>> renders it
>>
>
> Yes, and that works within established mechanisms very well.
>
> There is just one way to write tags. That has value.
You still have to chose: will I inline my markup or put it in a separate template?

>
>>
>>> 2) Having all such code coming out of a non-generated TagLib you write
>>> gives better visibility - for docs, IDEs etc
>>>
>> Currently I already get navigation, syntax coloring and code completion both
>> when writing the tags and when using them. But most important, typical UI
>> components that contain more markup then logic, are far more easier to write
>> and to read in a gsp
>>
>
> How do you get that completion? Surely it is only possible in an IDE after your generated sources have been compiled by the IDE?
correct

>> Just lik JSP and JSF have two ways of defining tags; in java or in
>> JSP/facelet. The ratio logic/markup determines the choice
>>
>
> I would never suggest JSP or JSF as a sound model for concepts :)
>
> Just because they do something, it does not make it good.
Agree, but being able to create a reusable component by merely copying part of a page is definitely a good thing.  The only feature I really miss after switching from JSF :)

>> Except for the above reasons, there is also marketing value: when my
>> colleagues tell about how easy you can create tags in JSP/JSF from a page
>> snippet, I just want to reply /grails can do that/ :)
>
>
> It can:
>
> class MyTagLib {
>    def myTag = { attrs ->
>       out << g.render(template:'/views/_tags/myTag', model:[attrs:attrs])
>    }
> }
Done this, but unfortunately it is:
a) not performant
b) a maintenance nightmare in larger projects because you constantly need to keep 2 pieces of code in sync for one component

> Also note that type safety and checking of attribute values etc is best done in real TagLib code. Otherwise you are doing a lot of Groovy code in a GSP which is bad.
I agree that too much code in a gsp is not good, but on the other hand too much markup in code is even worse: my IDE has good support for code in gsp's, but it doesn't tell me that I forgot to close a html tag inside a concatenation of String literals, nor does it show nesting etc. :(

> I still vote -1, this should remain in a plugin. If more hooks are needed to help it integrate better, add the hooks, but IMO don't add this feature to core.
Besides a few hooks, the impact and risks of this feature are very small, so why not add it since it is generally useful in IMO

Grtz,
Ivo


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Graeme Rocher
Administrator
On Wed, Mar 28, 2012 at 4:43 PM, Ivo Houbrechts <[hidden email]> wrote:

>>> - tags are much faster then templates
>>
>> Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?
>>
>> The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?
>
> When rendering a template, a page context needs to be constructed. This is not the case when calling a tag.
> In my current project, we have about 50 UI components that where first build using a tag + template. Since most tags call other tags that call other tags... we got hundreds of templates rendered per page making everything slow. Migrating to gsp tags fixed the performance issue.
>
>>
>>> - tags come with an API, docs and code completion
>>
>> There is no difference here to a tag that calls g:render.
> When I type "<c:box" , Intellij already adds the required attributes and has completion for the optional ones. When I type "<g:render", it doesn't have a clue about what's in the model.
> Which would you prefer:
> <c:box titleCode="my.title">...</c:box>
> or
> <g:render template="box" model="${titleCode: 'my.title}">...</g:template>
>
> I guess this is the reason why grails has both tags and templates :)
>
>>
>>> - gsp tags are placed in the taglib dir where they belong, not in the views
>>> dir
>>
>> Again this is a non-issue IMO. Its clear what a grails-app/views/_tags folder would be for.
> You can easily navigate from a tag to its corresponding template, but not back. With more then 50 components this is not exactly convenient :(
>
>>
>>> - using g:render, you need to define 2 things: the template and the tag that
>>> renders it
>>>
>>
>> Yes, and that works within established mechanisms very well.
>>
>> There is just one way to write tags. That has value.
> You still have to chose: will I inline my markup or put it in a separate template?
>
>>
>>>
>>>> 2) Having all such code coming out of a non-generated TagLib you write
>>>> gives better visibility - for docs, IDEs etc
>>>>
>>> Currently I already get navigation, syntax coloring and code completion both
>>> when writing the tags and when using them. But most important, typical UI
>>> components that contain more markup then logic, are far more easier to write
>>> and to read in a gsp
>>>
>>
>> How do you get that completion? Surely it is only possible in an IDE after your generated sources have been compiled by the IDE?
> correct
>
>>> Just lik JSP and JSF have two ways of defining tags; in java or in
>>> JSP/facelet. The ratio logic/markup determines the choice
>>>
>>
>> I would never suggest JSP or JSF as a sound model for concepts :)
>>
>> Just because they do something, it does not make it good.
> Agree, but being able to create a reusable component by merely copying part of a page is definitely a good thing.  The only feature I really miss after switching from JSF :)
>
>>> Except for the above reasons, there is also marketing value: when my
>>> colleagues tell about how easy you can create tags in JSP/JSF from a page
>>> snippet, I just want to reply /grails can do that/ :)
>>
>>
>> It can:
>>
>> class MyTagLib {
>>    def myTag = { attrs ->
>>       out << g.render(template:'/views/_tags/myTag', model:[attrs:attrs])
>>    }
>> }
> Done this, but unfortunately it is:
> a) not performant
> b) a maintenance nightmare in larger projects because you constantly need to keep 2 pieces of code in sync for one component
>
>> Also note that type safety and checking of attribute values etc is best done in real TagLib code. Otherwise you are doing a lot of Groovy code in a GSP which is bad.
> I agree that too much code in a gsp is not good, but on the other hand too much markup in code is even worse: my IDE has good support for code in gsp's, but it doesn't tell me that I forgot to close a html tag inside a concatenation of String literals, nor does it show nesting etc. :(
>
>> I still vote -1, this should remain in a plugin. If more hooks are needed to help it integrate better, add the hooks, but IMO don't add this feature to core.
> Besides a few hooks, the impact and risks of this feature are very small, so why not add it since it is generally useful in IMO


My vote is +1 because I do think it is generally useful

Although I think the g:inject tag should be removed and replaced with:

<g:set var="foo" bean="blah" />

To avoid introduction of a new tag the function of which is not
immediately obvious

Cheers

>
> Grtz,
> Ivo
>
>
> ---------------------------------------------------------------------
> 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: gsp taglib pull request

Marc Palmer Local

On 28 Mar 2012, at 16:18, Graeme Rocher wrote:

> On Wed, Mar 28, 2012 at 4:43 PM, Ivo Houbrechts <[hidden email]> wrote:
>>
>>> I still vote -1, this should remain in a plugin. If more hooks are needed to help it integrate better, add the hooks, but IMO don't add this feature to core.
>> Besides a few hooks, the impact and risks of this feature are very small, so why not add it since it is generally useful in IMO
>

"so why not" is definitely not good enough justification for me to change my vote I'm afraid, see below:

>
> My vote is +1 because I do think it is generally useful
>

Let me be clear: it is not that I do not think it is generally useful.

My issue is that I see no justification for adding it to *core* given that it confuses the concept of creating taglibs by adding another way to do it, with an ugly syntax, for the sake of some improved performance and saving a few lines of TagLib code.

To me those are bad reasons to add to core - where core is already bloated and in particular the GSP processing chain desperately convoluted to the point that nobody really wants to go there to do really important stuff like make Codec handling automatic.

Good reasons to add something to core for me would include:

* Performance boost for all users
* Simplification of existing core codebase
* Genuinely new ways of doing things

Keeping this out of core also has several distinct benefits:

1) Users can make use of it across Grails releases - in this case 1.3.x (I hope), 2.0 and 2.0.1 - given that in core it will not make it until 2.1 so that would exclude all 2.0.x users also

2) Putting it in core means that any plugins that use this form of GSP taglib would not work with versions of Grails prior to the release in which it is in included (2.1?)

3) I thought we were on a mission to pare down core as much as possible.

Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java/UX)

I offer commercial support for Grails plugins from as low as $50/mo.
For details see: http://grailsrocks.com

Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
Contributor @ http://grails.org |  Founder @ http://noticelocal.com
Developer @ http://weceem.org | Member @ http://spottymushroom.com
Twitter: http://twitter.com/wangjammer5 


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Marc Palmer Local
In reply to this post by houbie

On 28 Mar 2012, at 15:43, Ivo Houbrechts wrote:

>>> - tags are much faster then templates
>>
>> Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?
>>
>> The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?
>
> When rendering a template, a page context needs to be constructed. This is not the case when calling a tag.
> In my current project, we have about 50 UI components that where first build using a tag + template. Since most tags call other tags that call other tags... we got hundreds of templates rendered per page making everything slow. Migrating to gsp tags fixed the performance issue.
>

BTW do you have some hard numbers on the performance difference here between a tag like:

def myTag = { attrs, body ->
   // validate some attrs
   out << g.render(template:'/_tags/myTag', model:[attrs:attrs, body:body])
}

vs the taglibs generated from GSPs using your approach?

I ask because if there is a serious g.render overhead this needs to be tackled separately anyway because important plugins now rely on this mechanism - Grails Fields and the forthcoming Platform UI.

Marc
~ ~ ~
Marc Palmer
Freelancer (Grails/Groovy/Java/UX)

I offer commercial support for Grails plugins from as low as $50/mo.
For details see: http://grailsrocks.com

Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
Contributor @ http://grails.org |  Founder @ http://noticelocal.com
Developer @ http://weceem.org | Member @ http://spottymushroom.com
Twitter: http://twitter.com/wangjammer5 


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Lari Hotari -


This performance problem has been tackled in Grails 2.0 :
http://jira.grails.org/browse/GRAILS-7582


Lari





29.03.2012 14:15, Marc Palmer wrote:

> On 28 Mar 2012, at 15:43, Ivo Houbrechts wrote:
>
>>>> - tags are much faster then templates
>>> Can I ask how this is? You generate a TagLib from the GSP - but the GSP still gets executed when you invoke the "GSP tag" right?
>>>
>>> The body of the GSP Tag can call other taglibs can't it, so you have all the same overheads as a normal GSP pretty much?
>> When rendering a template, a page context needs to be constructed. This is not the case when calling a tag.
>> In my current project, we have about 50 UI components that where first build using a tag + template. Since most tags call other tags that call other tags... we got hundreds of templates rendered per page making everything slow. Migrating to gsp tags fixed the performance issue.
>>
> BTW do you have some hard numbers on the performance difference here between a tag like:
>
> def myTag = { attrs, body ->
>    // validate some attrs
>    out << g.render(template:'/_tags/myTag', model:[attrs:attrs, body:body])
> }
>
> vs the taglibs generated from GSPs using your approach?
>
> I ask because if there is a serious g.render overhead this needs to be tackled separately anyway because important plugins now rely on this mechanism - Grails Fields and the forthcoming Platform UI.
>
> Marc
> ~ ~ ~
> Marc Palmer
> Freelancer (Grails/Groovy/Java/UX)
>
> I offer commercial support for Grails plugins from as low as $50/mo.
> For details see: http://grailsrocks.com
>
> Blog: http://www.anyware.co.uk | Resumé: http://www.anyware.co.uk/marc
> Contributor @ http://grails.org |  Founder @ http://noticelocal.com
> Developer @ http://weceem.org | Member @ http://spottymushroom.com
> Twitter: http://twitter.com/wangjammer5 
>
>
> ---------------------------------------------------------------------
> 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: gsp taglib pull request

houbie
In reply to this post by Graeme Rocher
Graeme Rocher-4 wrote
Although I think the g:inject tag should be removed and replaced with:

<g:set var="foo" bean="blah" />
I changed the pull request with an updated g:set tag to replace the inject tag.
Note that the inject tag has already been pulled into the master branch!

grtz,
Ivo
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Graeme Rocher
Administrator
On Tue, Apr 10, 2012 at 11:52 AM, houbie <[hidden email]> wrote:

>
> Graeme Rocher-4 wrote
>>
>> Although I think the g:inject tag should be removed and replaced with:
>>
>> <g:set var="foo" bean="blah" />
>>
>
> I changed the pull request with an updated g:set tag to replace the inject
> tag.
> Note that the inject tag has already been pulled into the master branch!


We'll need to take this pull request to vote amongst the committers.
Please all core committers response with either +1 or -1 (no
discussion)

Me +1

Cheers


>
> grtz,
> Ivo
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/gsp-taglib-pull-request-tp4512023p4545087.html
> Sent from the Grails - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: gsp taglib pull request

smaldini
-1

On Tue, Apr 10, 2012 at 12:02 PM, Graeme Rocher <[hidden email]> wrote:
On Tue, Apr 10, 2012 at 11:52 AM, houbie <[hidden email]> wrote:
>
> Graeme Rocher-4 wrote
>>
>> Although I think the g:inject tag should be removed and replaced with:
>>
>> <g:set var="foo" bean="blah" />
>>
>
> I changed the pull request with an updated g:set tag to replace the inject
> tag.
> Note that the inject tag has already been pulled into the master branch!


We'll need to take this pull request to vote amongst the committers.
Please all core committers response with either +1 or -1 (no
discussion)

Me +1

Cheers


>
> grtz,
> Ivo
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/gsp-taglib-pull-request-tp4512023p4545087.html
> Sent from the Grails - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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





--
Stéphane MALDINI
--


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

pledbrook
We should potentially change the way that the 'tmpl' namespace is
implemented so it's closer to the feature set of gsp-taglibs, but I
agree with Marc that this will add yet another way to do
templates/tags in core. I'd prefer to see it kept as a plugin or as a
replacement for the 'tmpl' namespace.

-1

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

houbie
In reply to this post by Graeme Rocher
I closed my original pull request and submitted a new one with 2 small improvements:
- merge the g.inject tag into the g.set tag
- fix watchedResources for paths that do not start with './'

Grtz,
houbie
Reply | Threaded
Open this post in threaded view
|

Re: gsp taglib pull request

Graeme Rocher
Administrator
Thanks this has been merged

Cheers

On Wed, Jun 13, 2012 at 9:06 AM, houbie <[hidden email]> wrote:
I closed my original pull request and submitted a new one with 2 small
improvements:
- merge the g.inject tag into the g.set tag
- fix watchedResources for paths that do not start with './'

Grtz,
houbie

--
View this message in context: http://grails.1312388.n4.nabble.com/gsp-taglib-pull-request-tp4512023p4630029.html
Sent from the Grails - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
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