You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2003/08/19 20:21:56 UTC
[veltools] using jsp tags within velocity
hey, looks like WebWork2 has a developed several ways to render their custom
UI tags within velocity templates. i've toyed with the idea of finding some
way to do this with Struts tags in the past but never got around to it. i
haven't looked deep into this yet, but i think this could be a Very Useful
Thing (tm) for us to develop. it could greatly ease people's transition from
jsp to velocity. here's a couple of relevant links:
http://wiki.opensymphony.com/space/Using+WebWork+2+Tags+from+Velocity
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/opensymphony/webwork2/src/java/
com/opensymphony/webwork/views/velocity/
there seem to have been two approaches used: directives (AbstractTagDirective
and friends) and a tool of sorts (JSPTagAdapter). at first glance, i'm
partial to the directive approach. either way, given the popularity and
"standard" status of jsp, it's not going to be going away soon. so, i think
this sort of functionality would be a good fit in velocity-tools and worth
developing. what do you guys think?
i'm occupied with other work right now, but wanted to put this out there so i
don't forget about it and so anyone else who's interested can jump on it.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] using jsp tags within velocity
Posted by Claude Brisson <cl...@savoirweb.com>.
> Especially with Faces coming. Faces seem to have *a lot* of logic
> packed into the taglibs that could be good tapping into (e.g., UI agent
> sniffing, differential rendering, whatever). Otherwise, all that
> functionality would have to be duplicated in Velocity.
I guess the most useful ones **WILL** be duplicated anyway. I just have to "javadocize" my UI-agent tool before
contributing it. Will contribute as is if someone needs it. Works well. Also, it still uses gnu regexps instead of jakarta ones for
now, which
IMHO don't really matters for myself, but...
CloD
----- Original Message -----
From: "Matías Giovannini" <ma...@k-bell.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: vendredi 22 août 2003 17:18
Subject: Re: [veltools] using jsp tags within velocity <long>
> On Wednesday, August 20, 2003, at 06:35 PM, Nathan Bubna wrote:
>
> > good points. i hadn't really thought of it that way. i was just
> > thinking
> > this sort of thing could be a work saver/transition path for some
> > people.
> > sorta like the yang to Veltag's yin. personally, i'd never use it,
> > but the
> > idea intrigued me. it's one of those things i saw and the little kid
> > that
> > runs around my brain said "neato!"
> >
> > but let it be enough to say you've convinced me that putting this into
> > VelocityView or VelocityStruts would be a step in the wrong direction.
> > however, i still think it's a neato idea and would throw something
> > like this
> > in a contrib somewhere folder for those curious, desparate, or stupid
> > enough
> > to need/want it. :)
>
> Especially with Faces coming. Faces seem to have *a lot* of logic
> packed into the taglibs that could be good tapping into (e.g., UI agent
> sniffing, differential rendering, whatever). Otherwise, all that
> functionality would have to be duplicated in Velocity.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
Re: [veltools] using jsp tags within velocity
Posted by Matías Giovannini <ma...@k-bell.com>.
On Wednesday, August 20, 2003, at 06:35 PM, Nathan Bubna wrote:
> good points. i hadn't really thought of it that way. i was just
> thinking
> this sort of thing could be a work saver/transition path for some
> people.
> sorta like the yang to Veltag's yin. personally, i'd never use it,
> but the
> idea intrigued me. it's one of those things i saw and the little kid
> that
> runs around my brain said "neato!"
>
> but let it be enough to say you've convinced me that putting this into
> VelocityView or VelocityStruts would be a step in the wrong direction.
> however, i still think it's a neato idea and would throw something
> like this
> in a contrib somewhere folder for those curious, desparate, or stupid
> enough
> to need/want it. :)
Especially with Faces coming. Faces seem to have *a lot* of logic
packed into the taglibs that could be good tapping into (e.g., UI agent
sniffing, differential rendering, whatever). Otherwise, all that
functionality would have to be duplicated in Velocity.
Re: [veltools] using jsp tags within velocity
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Nathan said:
> > i think [JSP tags inside Velocity Templates] could be a Very Useful
> > Thing (tm) for us to develop.
> First impression, I am -1.
...
> The moral - direct access to the JSP taglib from Velocity might have
> helped in the short term for the developer, but it would have
> complicated the template and severely lessened the "Velocity Advantage"
> IMHO.
...
> > it could greatly ease people's transition from jsp to velocity.
> I am skeptical - I predict this might actually slow the transition. Why
> would developers bother with clean and simple Velocity macros if they
> can just wrap an [ugly taglib call] with funky directives like: #tag
> (myFoo "param1=<%foo%>")? I see bad things down that road. :-(
...
> Even if this did all just work - that #tag( select "label=Username"
> "name=username" ) will IMHO increase complexity and confusion because
> Developers may like/understand it, but I predict Designers will choke on
> having yet another layer of abstraction added to an already mysterious
> taglib.
good points. i hadn't really thought of it that way. i was just thinking
this sort of thing could be a work saver/transition path for some people.
sorta like the yang to Veltag's yin. personally, i'd never use it, but the
idea intrigued me. it's one of those things i saw and the little kid that
runs around my brain said "neato!"
but let it be enough to say you've convinced me that putting this into
VelocityView or VelocityStruts would be a step in the wrong direction.
however, i still think it's a neato idea and would throw something like this
in a contrib somewhere folder for those curious, desparate, or stupid enough
to need/want it. :)
> So here is my suggested alternative....
...
> Create a #select macro that takes an OptionsList data structure and does
> what html:select does...
...
> Here is an example macro for creating a select list from a list of
> Options.
>
> WidgetOptions implements an OptionsList interface: getList(), getName().
> And the List objects implement getCode(), isSelected(), getText(), and
> getName().
>
> #select($myform.WidgetOptions)
> -----
> ## Display a list of options...
> #macro (select $options)
> <select name="$options.name">
> <option value="-">Select one...</option>
> #foreach ($option in $options.list)
> <option value="$option.code" #if ($option.selected) SELECTED #end
> >$option.text</option>
> #end
> </select>
> #end
> -----
...
> I propose that this type of data structure and macro combination be
> discussed, reviewed, and added into the Example apps so first-time
> developers will see code like:
...
hmm. i don't like the OptionsList interface idea. what happens when you want
to add something like an onchange attribute to the select element? i know
it's not as simple as
#select( $FooOptions )
but i prefer something along the lines of
#macro( select $name $values $selected $onchange )
<select name="$!name"#if( $onchange ) onchange="$onchange"#end>
#foreach( $value in $values )
<option value="$value"#if( $value == $selected )
selected="true"#end>$value</option>
#end
</select>
#end
of course, it'd be ideal if Velocity had overloaded macros. then we could do
#macro( select $name $values )
...
#macro( select $name $values $selected )
...
and so on. hmm. maybe someday i'll start hacking at the velocity core
myself. there's things i'd like to add/fix but just haven't needed to badly
enough yet. anyway, my point is that i don't want to encourage legit view
logic and values creeping into java code because of prescribed interfaces for
our hypothetical standard macros. i'd rather have semi-longish lists of macro
parameters and encourage people to pass $null when they don't need them.
(e.g. #select( "myname" $myvalues $null $null ) ). which reminds me! did we
ever get a NULL token in velocity? some time ago that was in fairly high
demand and i seem to recall Geir saying he'd do it, but i don't remember if it
ever happened. hmm. that could come in handy here.
> If you've read this far... your name is probably Nathan, and I thank you
> for listening to me babel. <grin>
heh. my name is Nathan, and i thank you for your helpful babel. <grin>
Nathan Bubna
nathan@esha.com
Re: [veltools] using jsp tags within velocity
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Nathan said:
> > i think [JSP tags inside Velocity Templates] could be a Very Useful
> > Thing (tm) for us to develop.
> First impression, I am -1.
...
> The moral - direct access to the JSP taglib from Velocity might have
> helped in the short term for the developer, but it would have
> complicated the template and severely lessened the "Velocity Advantage"
> IMHO.
...
> > it could greatly ease people's transition from jsp to velocity.
> I am skeptical - I predict this might actually slow the transition. Why
> would developers bother with clean and simple Velocity macros if they
> can just wrap an [ugly taglib call] with funky directives like: #tag
> (myFoo "param1=<%foo%>")? I see bad things down that road. :-(
...
> Even if this did all just work - that #tag( select "label=Username"
> "name=username" ) will IMHO increase complexity and confusion because
> Developers may like/understand it, but I predict Designers will choke on
> having yet another layer of abstraction added to an already mysterious
> taglib.
good points. i hadn't really thought of it that way. i was just thinking
this sort of thing could be a work saver/transition path for some people.
sorta like the yang to Veltag's yin. personally, i'd never use it, but the
idea intrigued me. it's one of those things i saw and the little kid that
runs around my brain said "neato!"
but let it be enough to say you've convinced me that putting this into
VelocityView or VelocityStruts would be a step in the wrong direction.
however, i still think it's a neato idea and would throw something like this
in a contrib somewhere folder for those curious, desparate, or stupid enough
to need/want it. :)
> So here is my suggested alternative....
...
> Create a #select macro that takes an OptionsList data structure and does
> what html:select does...
...
> Here is an example macro for creating a select list from a list of
> Options.
>
> WidgetOptions implements an OptionsList interface: getList(), getName().
> And the List objects implement getCode(), isSelected(), getText(), and
> getName().
>
> #select($myform.WidgetOptions)
> -----
> ## Display a list of options...
> #macro (select $options)
> <select name="$options.name">
> <option value="-">Select one...</option>
> #foreach ($option in $options.list)
> <option value="$option.code" #if ($option.selected) SELECTED #end
> >$option.text</option>
> #end
> </select>
> #end
> -----
...
> I propose that this type of data structure and macro combination be
> discussed, reviewed, and added into the Example apps so first-time
> developers will see code like:
...
hmm. i don't like the OptionsList interface idea. what happens when you want
to add something like an onchange attribute to the select element? i know
it's not as simple as
#select( $FooOptions )
but i prefer something along the lines of
#macro( select $name $values $selected $onchange )
<select name="$!name"#if( $onchange ) onchange="$onchange"#end>
#foreach( $value in $values )
<option value="$value"#if( $value == $selected )
selected="true"#end>$value</option>
#end
</select>
#end
of course, it'd be ideal if Velocity had overloaded macros. then we could do
#macro( select $name $values )
...
#macro( select $name $values $selected )
...
and so on. hmm. maybe someday i'll start hacking at the velocity core
myself. there's things i'd like to add/fix but just haven't needed to badly
enough yet. anyway, my point is that i don't want to encourage legit view
logic and values creeping into java code because of prescribed interfaces for
our hypothetical standard macros. i'd rather have semi-longish lists of macro
parameters and encourage people to pass $null when they don't need them.
(e.g. #select( "myname" $myvalues $null $null ) ). which reminds me! did we
ever get a NULL token in velocity? some time ago that was in fairly high
demand and i seem to recall Geir saying he'd do it, but i don't remember if it
ever happened. hmm. that could come in handy here.
> If you've read this far... your name is probably Nathan, and I thank you
> for listening to me babel. <grin>
heh. my name is Nathan, and i thank you for your helpful babel. <grin>
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] using jsp tags within velocity
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
Boy, this is long... :) Inline -
On Wednesday, August 20, 2003, at 04:09 PM, Tim Colson wrote:
>
> Anecote: I presented Velocity Tools to a Java User group, and it mostly
> went well. Except for one chap "I like JSP taglibs" who felt that the
> Struts "nested properties jsp tag" was uber-important. I noted how the
> syntax of the tag was probably difficult for an HTML designer to use,
> compared to how Velocity can work with nested data:
>
> #foreach ($foo in $FooList)
> Outter $foo
> #foreach ($nestedfoo in $foo.NestedFooList)
> Inner $nestedfoo
> #end
> #end
>
> He was mostly convinced after seeing an example that took a short few
> minutes to code, but suggested that for folks unfamiliar with Velocity,
> it would be helpful to have a library of examples/macros that showed
> how
> to do the Struts tags using Velocity. I have heard this before from
> Developers who have learned how to use <html:foo name="<% bar.bleck %>"
> />
This could be done as documentation too, showing people how to migrate.
You might be most effective in identifying the common [anti] patterns
used by JSP users, and show how the same thing is achieved with
Velocity.
>
[SNIP]
>
> So here is my suggested alternative....
>
> I see two problems:
> 1) Lazy Developers (aren't we all?)
> 2) UI Designers understand <select> tags but NOT <html:select>
>
> This combination means UI folks can not edit foo.jsp, instead they
> provide "revised mockups" in HTML which the Developer must tediously
> transcribe into JSP.
>
I'm not sure if that's true. I don't do JSP, but I thought that
support in design tools was pretty good...
>
> How to make everybody happier and more effective using Velocity?
>
> Create a #select macro that takes an OptionsList data structure and
> does
> what html:select does... but better because :
> 1) Developer can be lazy and write #select($FooOptions) - Yay!
> 2) UI Designer can understand the #select macro because it's just
> Velocity template stuff...and they can re-write as
> #CoolerSelect($FooOptions)
or just override the base #select() with their own implementation...
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
RE: [veltools] using jsp tags within velocity
Posted by Tim Colson <tc...@cisco.com>.
Say there Mr. Nathan :-)
> i think [JSP tags inside Velocity Templates] could be a Very Useful
> Thing (tm) for us to develop.
First impression, I am -1.
I've got a long-winded reason why, but in brief I believe creating some
standard datastructures and default macros would better help folks
transition to Velocity for webapps.
And now for the long-winded reply... :-)
----
Anecote: I presented Velocity Tools to a Java User group, and it mostly
went well. Except for one chap "I like JSP taglibs" who felt that the
Struts "nested properties jsp tag" was uber-important. I noted how the
syntax of the tag was probably difficult for an HTML designer to use,
compared to how Velocity can work with nested data:
#foreach ($foo in $FooList)
Outter $foo
#foreach ($nestedfoo in $foo.NestedFooList)
Inner $nestedfoo
#end
#end
He was mostly convinced after seeing an example that took a short few
minutes to code, but suggested that for folks unfamiliar with Velocity,
it would be helpful to have a library of examples/macros that showed how
to do the Struts tags using Velocity. I have heard this before from
Developers who have learned how to use <html:foo name="<% bar.bleck %>"
/>
The moral - direct access to the JSP taglib from Velocity might have
helped in the short term for the developer, but it would have
complicated the template and severely lessened the "Velocity Advantage"
IMHO.
> it could greatly ease people's transition from jsp to velocity.
I am skeptical - I predict this might actually slow the transition. Why
would developers bother with clean and simple Velocity macros if they
can just wrap an [ugly taglib call] with funky directives like: #tag
(myFoo "param1=<%foo%>")? I see bad things down that road. :-(
> there seem to have been two approaches used: directives
(AbstractTagDirective
> and friends) and a tool of sorts (JSPTagAdapter).
I looked around and they are interesting. The JSP taglibs seem to be
written specifically with Velocity hooks. And the adapter looks like a
way to insert a fake JSPWriter so output can be redirected. I can't tell
though if these tweaks would work with black-box tags that may be
difficult to modify. (ex. Developer X wants to use off the shelf
compiled taglib).
Even if this did all just work - that #tag( select "label=Username"
"name=username" ) will IMHO increase complexity and confusion because
Developers may like/understand it, but I predict Designers will choke on
having yet another layer of abstraction added to an already mysterious
taglib.
So here is my suggested alternative....
I see two problems:
1) Lazy Developers (aren't we all?)
Most like the struts tag because they are lazy and don't want to
write out the interation to create a list of options for a simple HTML
<select> tag - they don't mind using funky runtime expressions and
misleading attrib names, ex. <html:select name="beanNameHere"
onclick="<% foo.getClick() %>" />
2) UI Designers understand <select> tags but NOT <html:select>
- Because some attribs aren't even mapped directly (ex. name attrib),
and runtime expressions are mysterious voodoo
This combination means UI folks can not edit foo.jsp, instead they
provide "revised mockups" in HTML which the Developer must tediously
transcribe into JSP.
How to make everybody happier and more effective using Velocity?
Create a #select macro that takes an OptionsList data structure and does
what html:select does... but better because :
1) Developer can be lazy and write #select($FooOptions) - Yay!
2) UI Designer can understand the #select macro because it's just
Velocity template stuff...and they can re-write as
#CoolerSelect($FooOptions)
I believe the key is to provide a simple soln for the Developer, but
also give Designers understandable markup they can modify. Then when the
UI needs tweaking, the Designer can directly modify *.vm and the
Developer can keep working on real bugs.
The other key comes for free with the VelocityTools/Struts MVC
architecture... if it ain't broken, don't fix it. Meaning that
developers can continue using JSP's, but can try velocity templates for
new features. This protects the JSP investment, and reduces the risk of
a new (to them) technology.
Here is an example macro for creating a select list from a list of
Options.
WidgetOptions implements an OptionsList interface: getList(), getName().
And the List objects implement getCode(), isSelected(), getText(), and
getName().
#select($myform.WidgetOptions)
-----
## Display a list of options...
#macro (select $options)
<select name="$options.name">
<option value="-">Select one...</option>
#foreach ($option in $options.list)
<option value="$option.code" #if ($option.selected) SELECTED #end
>$option.text</option>
#end
</select>
#end
-----
(I even have Intellij live templates so this shortcut magically pops up
with the required params when starting to type "selec..")
I propose that this type of data structure and macro combination be
discussed, reviewed, and added into the Example apps so first-time
developers will see code like:
<form name="$myform.name" >
#input($myform.WidgetName)
#select($myform.WidgetOptions)
#select($myform.FooOptions)
</form>
And then in the struts_html_library.vm, Designers can see/change what
#input looks like in HTML.
Going one step further... if macro inline replacement is turned off,
then the config could list struts_html_library_custom.vm,
struts_html_library.vm and the Designer could then over-ride macro
(input $name) with a custom HTML implementation.
If you've read this far... your name is probably Nathan, and I thank you
for listening to me babel. <grin>
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [veltools] using jsp tags within velocity
Posted by Tim Colson <tc...@cisco.com>.
Say there Mr. Nathan :-)
> i think [JSP tags inside Velocity Templates] could be a Very Useful
> Thing (tm) for us to develop.
First impression, I am -1.
I've got a long-winded reason why, but in brief I believe creating some
standard datastructures and default macros would better help folks
transition to Velocity for webapps.
And now for the long-winded reply... :-)
----
Anecote: I presented Velocity Tools to a Java User group, and it mostly
went well. Except for one chap "I like JSP taglibs" who felt that the
Struts "nested properties jsp tag" was uber-important. I noted how the
syntax of the tag was probably difficult for an HTML designer to use,
compared to how Velocity can work with nested data:
#foreach ($foo in $FooList)
Outter $foo
#foreach ($nestedfoo in $foo.NestedFooList)
Inner $nestedfoo
#end
#end
He was mostly convinced after seeing an example that took a short few
minutes to code, but suggested that for folks unfamiliar with Velocity,
it would be helpful to have a library of examples/macros that showed how
to do the Struts tags using Velocity. I have heard this before from
Developers who have learned how to use <html:foo name="<% bar.bleck %>"
/>
The moral - direct access to the JSP taglib from Velocity might have
helped in the short term for the developer, but it would have
complicated the template and severely lessened the "Velocity Advantage"
IMHO.
> it could greatly ease people's transition from jsp to velocity.
I am skeptical - I predict this might actually slow the transition. Why
would developers bother with clean and simple Velocity macros if they
can just wrap an [ugly taglib call] with funky directives like: #tag
(myFoo "param1=<%foo%>")? I see bad things down that road. :-(
> there seem to have been two approaches used: directives
(AbstractTagDirective
> and friends) and a tool of sorts (JSPTagAdapter).
I looked around and they are interesting. The JSP taglibs seem to be
written specifically with Velocity hooks. And the adapter looks like a
way to insert a fake JSPWriter so output can be redirected. I can't tell
though if these tweaks would work with black-box tags that may be
difficult to modify. (ex. Developer X wants to use off the shelf
compiled taglib).
Even if this did all just work - that #tag( select "label=Username"
"name=username" ) will IMHO increase complexity and confusion because
Developers may like/understand it, but I predict Designers will choke on
having yet another layer of abstraction added to an already mysterious
taglib.
So here is my suggested alternative....
I see two problems:
1) Lazy Developers (aren't we all?)
Most like the struts tag because they are lazy and don't want to
write out the interation to create a list of options for a simple HTML
<select> tag - they don't mind using funky runtime expressions and
misleading attrib names, ex. <html:select name="beanNameHere"
onclick="<% foo.getClick() %>" />
2) UI Designers understand <select> tags but NOT <html:select>
- Because some attribs aren't even mapped directly (ex. name attrib),
and runtime expressions are mysterious voodoo
This combination means UI folks can not edit foo.jsp, instead they
provide "revised mockups" in HTML which the Developer must tediously
transcribe into JSP.
How to make everybody happier and more effective using Velocity?
Create a #select macro that takes an OptionsList data structure and does
what html:select does... but better because :
1) Developer can be lazy and write #select($FooOptions) - Yay!
2) UI Designer can understand the #select macro because it's just
Velocity template stuff...and they can re-write as
#CoolerSelect($FooOptions)
I believe the key is to provide a simple soln for the Developer, but
also give Designers understandable markup they can modify. Then when the
UI needs tweaking, the Designer can directly modify *.vm and the
Developer can keep working on real bugs.
The other key comes for free with the VelocityTools/Struts MVC
architecture... if it ain't broken, don't fix it. Meaning that
developers can continue using JSP's, but can try velocity templates for
new features. This protects the JSP investment, and reduces the risk of
a new (to them) technology.
Here is an example macro for creating a select list from a list of
Options.
WidgetOptions implements an OptionsList interface: getList(), getName().
And the List objects implement getCode(), isSelected(), getText(), and
getName().
#select($myform.WidgetOptions)
-----
## Display a list of options...
#macro (select $options)
<select name="$options.name">
<option value="-">Select one...</option>
#foreach ($option in $options.list)
<option value="$option.code" #if ($option.selected) SELECTED #end
>$option.text</option>
#end
</select>
#end
-----
(I even have Intellij live templates so this shortcut magically pops up
with the required params when starting to type "selec..")
I propose that this type of data structure and macro combination be
discussed, reviewed, and added into the Example apps so first-time
developers will see code like:
<form name="$myform.name" >
#input($myform.WidgetName)
#select($myform.WidgetOptions)
#select($myform.FooOptions)
</form>
And then in the struts_html_library.vm, Designers can see/change what
#input looks like in HTML.
Going one step further... if macro inline replacement is turned off,
then the config could list struts_html_library_custom.vm,
struts_html_library.vm and the Designer could then over-ride macro
(input $name) with a custom HTML implementation.
If you've read this far... your name is probably Nathan, and I thank you
for listening to me babel. <grin>
Cheers,
Timo
Re: [veltools] using jsp tags within velocity
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 19, 2003, at 02:21 PM, Nathan Bubna wrote:
> hey, looks like WebWork2 has a developed several ways to render their
> custom
> UI tags within velocity templates. i've toyed with the idea of
> finding some
> way to do this with Struts tags in the past but never got around to
> it. i
> haven't looked deep into this yet, but i think this could be a Very
> Useful
> Thing (tm) for us to develop. it could greatly ease people's
> transition from
> jsp to velocity. here's a couple of relevant links:
>
> http://wiki.opensymphony.com/space/Using+WebWork+2+Tags+from+Velocity
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/opensymphony/webwork2/
> src/java/
> com/opensymphony/webwork/views/velocity/
>
> there seem to have been two approaches used: directives
> (AbstractTagDirective
> and friends) and a tool of sorts (JSPTagAdapter). at first glance, i'm
> partial to the directive approach. either way, given the popularity
> and
> "standard" status of jsp, it's not going to be going away soon. so, i
> think
> this sort of functionality would be a good fit in velocity-tools and
> worth
> developing. what do you guys think?
I think the tool is the way to go, and after that, an optional
directive. I say optional because tying the velocity core to the drek
that is JSP will get a
(can you guess...)
(wait for it...)
-1
from me.
The only advantage that the directive approach has, I believe, is that
you can give it more pointy-bracket body source to consume. I don't
necessarily see what's wrong with that, other than the queasiness
induced in the reader of same. Just thinking out loud -tThe problem
with the body could be that we'd have to fully support the body-as-JSP,
including JSTL, etc
If the tags people want to use don't need a body, I would think that
mocking up the JSP context/environment in a tool would be a good way.
There must be countless examples of this out there.
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)