Re: [tools] Ideas about future Velocity Tools features
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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
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 signature.asc Description: OpenPGP digital signature
Re: [tools] Ideas about future Velocity Tools features
2010/12/10 Nathan Bubna nbu...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
2010/12/11 Antonio Petrelli antonio.petre...@gmail.com: 2010/12/10 Nathan Bubna nbu...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
2010/12/9 Claude Brisson cla...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
On Fri, Dec 10, 2010 at 12:43 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2010/12/9 Claude Brisson cla...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
On Thu, Dec 9, 2010 at 2:16 AM, Antonio Petrelli antonio.petre...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
2010/12/10 Nathan Bubna nbu...@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 { DequeObject 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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
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 antonio.petre...@gmail.com wrote: 2010/12/10 Nathan Bubna nbu...@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 { DequeObject 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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
2010/12/9 Claude Brisson cla...@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-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Ideas about future Velocity Tools features
(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 Brissoncla...@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-unsubscr...@velocity.apache.org For additional commands, e-mail:dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org