taglib closures reused

[Dierk König]

Hi,

taglib closure properties are used in gsp pages like
 <g:foo bar="baz"/>
. Is it intended that they can be reused in Scriptlets like
 <% g.foo(bar:'baz') %>
and when rendering from a controller action like
 g.foo(bar:'baz')
?

This would alleviate refactorings from scaffolded
gsp pages to less-duplication solutions.

cheers
Mittie

[graemer]

On 11/03/06, Dierk Koenig <[hidden email]> wrote:
> Hi,
>
> taglib closure properties are used in gsp pages like
>  <g:foo bar="baz"/>
> . Is it intended that they can be reused in Scriptlets like
>  <% g.foo(bar:'baz') %>
They can already be used within scriptlets and gstring expressions
(without the g: though). this is useful when working with existing
tags eg.

<a href="${createLink(action:'someAction')}">my link</a>

> and when rendering from a controller action like
>  g.foo(bar:'baz')
> ?

I imagine they could be made available in a controller, what we would
have to do is get the controlllr to change the meta class of the tag
lib to use a StringWriter (instead of the response writer) and then
return the result to the controller because obviously they write to a
'out' variable at the moment.


>
> This would alleviate refactorings from scaffolded
> gsp pages to less-duplication solutions.
Indeed

Graeme

>
> cheers
> Mittie
>

[Dierk König]

> > taglib closure properties are used in gsp pages like
> >  <g:foo bar="baz"/>
> > . Is it intended that they can be reused in Scriptlets like
> >  <% g.foo(bar:'baz') %>
> They can already be used within scriptlets and gstring expressions
> (without the g: though). this is useful when working with existing
> tags eg.
>
> <a href="${createLink(action:'someAction')}">my link</a>

cool. We need to highlight this in the docs.
Maybe add a tutorial (;-)) about how to refactor from
scaffolded view to a DRY solution.

> > and when rendering from a controller action like
> >  g.foo(bar:'baz')
> > ?
>
> I imagine they could be made available in a controller, what we would
> have to do is get the controlllr to change the meta class of the tag
> lib to use a StringWriter (instead of the response writer) and then
> return the result to the controller because obviously they write to a
> 'out' variable at the moment.

We need to care about multithreading then. Different threads may use
the same method from a gsp and a controller. We would probably need
different taglib objects for them and 'inject' the out
variable.

cheers
Mittie

[graemer]

On 11/03/06, Dierk Koenig <[hidden email]> wrote:

> > > taglib closure properties are used in gsp pages like
> > >  <g:foo bar="baz"/>
> > > . Is it intended that they can be reused in Scriptlets like
> > >  <% g.foo(bar:'baz') %>
> > They can already be used within scriptlets and gstring expressions
> > (without the g: though). this is useful when working with existing
> > tags eg.
> >
> > <a href="${createLink(action:'someAction')}">my link</a>
>
> cool. We need to highlight this in the docs.
> Maybe add a tutorial (;-)) about how to refactor from
> scaffolded view to a DRY solution.

Indeed

>
> > > and when rendering from a controller action like
> > >  g.foo(bar:'baz')
> > > ?
> >
> > I imagine they could be made available in a controller, what we would
> > have to do is get the controlllr to change the meta class of the tag
> > lib to use a StringWriter (instead of the response writer) and then
> > return the result to the controller because obviously they write to a
> > 'out' variable at the moment.
>
> We need to care about multithreading then. Different threads may use
> the same method from a gsp and a controller. We would probably need
> different taglib objects for them and 'inject' the out
> variable.

New tag library instances are created per request anyway and cached as
a request attribute, so this shouldn't be too hard to do.. the
controller would need to delegate to them in a try/finally block
setting the 'out' property that wraps a StringWriter in a PrintWriter
and then retrieves the resulting value and returns it

I dont imagine that body tags would make much sense called from a
controller though

Graeme

>
> cheers
> Mittie
>