You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Antonio Petrelli <an...@gmail.com> on 2010/12/09 11:16:11 UTC
[tools] Ideas about future Velocity Tools features
Hi all
I am thinking about new features for Velocity Tools.
One can be included into 2.1 version: JSP tag library inclusion in
Velocity templates.
I think this would be an interesting feature, because there is a lot
of tag libraries out there. In particular what I love much:
DisplayTag.
Including JSP taglibs is a very useful feature of Freemarker and
Velocity is well behind it.
I am thinking of implementing it using directives (not tools) because
tools do not have body.
I will start working on it at once in the trunk, stop me at any time
and I will revert the job if you don't want it.
About something in a distant future, we can remove the dependency on
servlets technology for Velocity Tools.
What I've been doing in Tiles sandbox is extracting an API and a
series of technology-supporting modules to abstract the concept of
"request". You can see the result here:
http://svn.apache.org/repos/asf/tiles/sandbox/trunk/tiles-request/
This can be useful for Velocity Tools to use any technology that
implements this API (currently servlets, portlets, JSP, Velocity and
Freemarker).
If Velocity adopts this library, it can work, for example, under a
portlet environment without using a separate servlet.
This library works well in the sandboxed version of Tiles, the probable Tiles 3.
Moreover, this tiles-request library is used by another subproject,
"tiles-autotag" to generate JSP tags, Velocity directives and
Freemarker directive models starting from simple classes with an
"execute" method. Again, this works in sandboxed Tiles:
http://svn.apache.org/repos/asf/tiles/sandbox/trunk/tiles-autotag/
One idea that today has come to my mind is to move this library as a
subproject of Velocity, since it uses Velocity intensively to generate
tags.
Thoughts?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Nathan Bubna <nb...@gmail.com>.
On Sat, Dec 11, 2010 at 4:32 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/12/10 Nathan Bubna <nb...@gmail.com>:
>> Ay, that's a example of usage, but not a usecase, per se, as it
>> doesn't provide any motive or story. Is this something for end users?
>> for component developers? for framework integration? Given the end
>> product being a tool for end users to use, i assume it is not
>> something end users themselves will use.
>
> It is something for tag developers that want their tags to be
> available under various template technologies.
got it. so both framework and component devs would use it.
> But I cann't see your point.
no point to see. just a question/clarification.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/11 Antonio Petrelli <an...@gmail.com>:
> 2010/12/10 Nathan Bubna <nb...@gmail.com>:
>> Ay, that's a example of usage, but not a usecase, per se, as it
>> doesn't provide any motive or story. Is this something for end users?
>> for component developers? for framework integration? Given the end
>> product being a tool for end users to use, i assume it is not
>> something end users themselves will use.
>
> It is something for tag developers that want their tags to be
> available under various template technologies.
> But I cann't see your point.
Since Autotag is staying at Tiles according to latest news, it does
not really matter now.
I wanted only to save a part of Tiles in another project. Tiles is not
dying (yet :-D )
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/10 Nathan Bubna <nb...@gmail.com>:
> Ay, that's a example of usage, but not a usecase, per se, as it
> doesn't provide any motive or story. Is this something for end users?
> for component developers? for framework integration? Given the end
> product being a tool for end users to use, i assume it is not
> something end users themselves will use.
It is something for tag developers that want their tags to be
available under various template technologies.
But I cann't see your point.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Nathan Bubna <nb...@gmail.com>.
Ay, that's a example of usage, but not a usecase, per se, as it
doesn't provide any motive or story. Is this something for end users?
for component developers? for framework integration? Given the end
product being a tool for end users to use, i assume it is not
something end users themselves will use.
On Fri, Dec 10, 2010 at 12:38 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/12/10 Nathan Bubna <nb...@gmail.com>:
>> I haven't actually looked at the autotag stuff. Can you give an
>> example usecase?
>
> Write this:
> <snip>
> public class PutAttributeModel {
>
> public void execute(@Parameter(required = true) String name, Object value,
> String expression, String role, String type, boolean cascade,
> Request request, ModelBody modelBody) throws IOException {
> Deque<Object> composeStack = ComposeStackUtil.getComposeStack(request);
> Attribute attribute = new Attribute();
> composeStack.push(attribute);
> String currentBody = modelBody.evaluateAsString();
> TilesContainer container = TilesAccess.getCurrentContainer(request);
> attribute = (Attribute) composeStack.pop();
> putAttributeInParent(attribute, container, composeStack, name,
> value, expression, currentBody, role, type, cascade, request);
> }
> </snip>
>
> And automatically have JSP tags, Freemarker directive models and
> Velocity directive (one parameter: a map) mapping all that parameters.
> Notice the compose stack (allows to nest tags between them in a
> technology agnostic way), the Request (request abstraction) and
> ModelBody (tag/directive body abstraction).
> No more implicit parameter maps, no more TLDs to write, only a simple
> "execute" method with explicit parameters.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/10 Nathan Bubna <nb...@gmail.com>:
> I haven't actually looked at the autotag stuff. Can you give an
> example usecase?
Write this:
<snip>
public class PutAttributeModel {
public void execute(@Parameter(required = true) String name, Object value,
String expression, String role, String type, boolean cascade,
Request request, ModelBody modelBody) throws IOException {
Deque<Object> composeStack = ComposeStackUtil.getComposeStack(request);
Attribute attribute = new Attribute();
composeStack.push(attribute);
String currentBody = modelBody.evaluateAsString();
TilesContainer container = TilesAccess.getCurrentContainer(request);
attribute = (Attribute) composeStack.pop();
putAttributeInParent(attribute, container, composeStack, name,
value, expression, currentBody, role, type, cascade, request);
}
</snip>
And automatically have JSP tags, Freemarker directive models and
Velocity directive (one parameter: a map) mapping all that parameters.
Notice the compose stack (allows to nest tags between them in a
technology agnostic way), the Request (request abstraction) and
ModelBody (tag/directive body abstraction).
No more implicit parameter maps, no more TLDs to write, only a simple
"execute" method with explicit parameters.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Nathan Bubna <nb...@gmail.com>.
On Thu, Dec 9, 2010 at 2:16 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> Hi all
> I am thinking about new features for Velocity Tools.
>
> One can be included into 2.1 version: JSP tag library inclusion in
> Velocity templates.
> I think this would be an interesting feature, because there is a lot
> of tag libraries out there. In particular what I love much:
> DisplayTag.
> Including JSP taglibs is a very useful feature of Freemarker and
> Velocity is well behind it.
> I am thinking of implementing it using directives (not tools) because
> tools do not have body.
> I will start working on it at once in the trunk, stop me at any time
> and I will revert the job if you don't want it.
sounds fine to me. i've looked into doing this myself several times.
you might want to peruse the list archives for previous discussions
about syntax/implementation possibilities. i know it's been discussed
at least once.
> About something in a distant future, we can remove the dependency on
> servlets technology for Velocity Tools.
> What I've been doing in Tiles sandbox is extracting an API and a
> series of technology-supporting modules to abstract the concept of
> "request". You can see the result here:
> http://svn.apache.org/repos/asf/tiles/sandbox/trunk/tiles-request/
> This can be useful for Velocity Tools to use any technology that
> implements this API (currently servlets, portlets, JSP, Velocity and
> Freemarker).
sounds fine. some work has already been done toward this (i.e.
VelocityView -> VVTag and VVServlet). it could be nice to see portlet
support and amusing to announce that VelocityTools works in
Freemarker, though i'm not sure anyone would necessarily want that.
> If Velocity adopts this library, it can work, for example, under a
> portlet environment without using a separate servlet.
> This library works well in the sandboxed version of Tiles, the probable Tiles 3.
>
> Moreover, this tiles-request library is used by another subproject,
> "tiles-autotag" to generate JSP tags, Velocity directives and
> Freemarker directive models starting from simple classes with an
> "execute" method. Again, this works in sandboxed Tiles:
> http://svn.apache.org/repos/asf/tiles/sandbox/trunk/tiles-autotag/
> One idea that today has come to my mind is to move this library as a
> subproject of Velocity, since it uses Velocity intensively to generate
> tags.
I haven't actually looked at the autotag stuff. Can you give an
example usecase?
>
> Thoughts?
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Dec 10, 2010 at 12:43 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/12/9 Claude Brisson <cl...@renegat.net>:
>> (sorry, truncated mail)
>>
>> I was pretty sure of that, kinda not really scared :-)
>>
>> Yes, Tiles abstractions look quite interesting, I'm a bit more dubitative
>> about JSPs, since raw tools are so handy, but maybe there is a crucial JSP
>> library I'm not aware of.
>
> Not crucial, but somewhat handy. Who used DisplayTag knows what I
> mean: a tag library that manages sorting and pagination (internal and
> external), alternate coloring etc. IOW, all the aspects of a table of
> results that you might imagine.
Yeah, DisplayTag is always the one that comes up in these
conversations, but i'm sure other tags would be used if the feature
was available.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/16 Christopher Schultz <ch...@christopherschultz.net>:
> Antonio,
>
> On 12/10/2010 3:43 AM, Antonio Petrelli wrote:
>> Who used DisplayTag knows what I
>> mean: a tag library that manages sorting and pagination (internal and
>> external), alternate coloring etc. IOW, all the aspects of a table of
>> results that you might imagine.
>
> I've developed what I think is a great Velocimacro that acts as a pager.
> 116 lines including comments, debug output, etc. I'd be happy to share
> it with the community... I'd probably get feedback about how it could be
> improved :)
Chris, since you are a committer, you can add it. If you don't feel
comfortable to commit in the main trunk, you can think of committing
it in the sandbox.
> The AlternatorTool does a great job for alternate coloring.
>
> Does DisplayTag do anything on top of those, or is the idea that it's
> all rolled into one tag so you don't have to piece-together your solution?
I don't want to include *only* DisplayTag, it's only the most useful
JSP tag library I have in mind. What I'm finishing is a generic Maven
plugin that wraps any JSP tag library, not only DisplayTag.
OTOH, DisplayTag does pagination (simple and external), sorting
(simple and external) and it's easy to configure and to customize.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Antonio,
On 12/10/2010 3:43 AM, Antonio Petrelli wrote:
> Who used DisplayTag knows what I
> mean: a tag library that manages sorting and pagination (internal and
> external), alternate coloring etc. IOW, all the aspects of a table of
> results that you might imagine.
I've developed what I think is a great Velocimacro that acts as a pager.
116 lines including comments, debug output, etc. I'd be happy to share
it with the community... I'd probably get feedback about how it could be
improved :)
The AlternatorTool does a great job for alternate coloring.
Does DisplayTag do anything on top of those, or is the idea that it's
all rolled into one tag so you don't have to piece-together your solution?
-chris
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/9 Claude Brisson <cl...@renegat.net>:
> (sorry, truncated mail)
>
> I was pretty sure of that, kinda not really scared :-)
>
> Yes, Tiles abstractions look quite interesting, I'm a bit more dubitative
> about JSPs, since raw tools are so handy, but maybe there is a crucial JSP
> library I'm not aware of.
Not crucial, but somewhat handy. Who used DisplayTag knows what I
mean: a tag library that manages sorting and pagination (internal and
external), alternate coloring etc. IOW, all the aspects of a table of
results that you might imagine.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Claude Brisson <cl...@renegat.net>.
(sorry, truncated mail)
I was pretty sure of that, kinda not really scared :-)
Yes, Tiles abstractions look quite interesting, I'm a bit more
dubitative about JSPs, since raw tools are so handy, but maybe there is
a crucial JSP library I'm not aware of.
Claude
The use of JSPs, especially,
On 09/12/2010 16:59, Claude Brisson wrote:
> I was pretty sure of that,
>
> On 09/12/2010 13:59, Antonio Petrelli wrote:
>> 2010/12/9 Claude Brisson<cl...@renegat.net>:
>>
>>> On 09/12/2010 11:16, Antonio Petrelli wrote:
>>>
>>> [...]
>>>
>>>
>>>> About something in a distant future, we can remove the dependency on
>>>> servlets technology for Velocity Tools.
>>>>
>>>>
>>> This objective looks rather strange, and quite scaring to me. JSPs is not
>>> everyone's choice, neither is Tiles or Struts. Using Tools within a plain
>>> J2EE servlet can also be a very good choice.
>>>
>>> As long as everything is done to let developers decide what they want to
>>> use, I've of course nothing against it, though.
>>>
>> Don't be scared, the removal of the dependency does not mean the
>> removal of support!
>> What I meant is using an abstraction of what we need of servlets (in
>> particular a request/response pair and a writer) to allow the use in
>> other environments, in particular portlets.
>> I never meant to remove servlet *support*.
>>
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail:dev-help@velocity.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/9 Claude Brisson <cl...@renegat.net>:
> On 09/12/2010 11:16, Antonio Petrelli wrote:
>
> [...]
>
>> About something in a distant future, we can remove the dependency on
>> servlets technology for Velocity Tools.
>>
>
> This objective looks rather strange, and quite scaring to me. JSPs is not
> everyone's choice, neither is Tiles or Struts. Using Tools within a plain
> J2EE servlet can also be a very good choice.
>
> As long as everything is done to let developers decide what they want to
> use, I've of course nothing against it, though.
Don't be scared, the removal of the dependency does not mean the
removal of support!
What I meant is using an abstraction of what we need of servlets (in
particular a request/response pair and a writer) to allow the use in
other environments, in particular portlets.
I never meant to remove servlet *support*.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
Posted by Claude Brisson <cl...@renegat.net>.
On 09/12/2010 11:16, Antonio Petrelli wrote:
[...]
> About something in a distant future, we can remove the dependency on
> servlets technology for Velocity Tools.
>
This objective looks rather strange, and quite scaring to me. JSPs is
not everyone's choice, neither is Tiles or Struts. Using Tools within a
plain J2EE servlet can also be a very good choice.
As long as everything is done to let developers decide what they want to
use, I've of course nothing against it, though.
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org