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 <nb...@gmail.com> on 2006/03/09 23:28:08 UTC
[veltools] what next...
FYI: this email will be boring personal background followed by
relevant organizational and technical stuff; skip ahead if you only
want the latter. :)
So... i've been playing around with a fair number of next steps for
VelocityTools. at this point, my local branch is well beyond the
point that i can easily check stuff in piece by piece. everything has
begun to overlap and a variety of half-finished ideas are littered
about. this has all been compounded by a myriad of personal life
demands on my time over the past year and the fact that my employer
has me working on a mix of Turbine/Velocity and SpringMVC/JSP apps
over that same year. while i've been able to use GenericTools classes
for the former apps, the reality is that i haven't used VelocityView
or VelocityStruts in quite some time. and it doesn't look like we'll
ever use VelocityStruts (at least in its current incarnation) at my
paid job. I, unfortunately, have had little leverage in our
technology choices since i shifted to the part-time work + part-time
grad studies life. i'm in the process of shifting back to full-time,
but it may be some time until an opportunity to influence a new
project arises.
all these things (in coincidental conjunction with coming changes in
Jakarta's project organization and the always-not-quite-ready Velocity
1.5) leave a number of questions, ideas, and concerns about what is
next for VelocityTools.
Concern #1 - VelocityStruts 1.2 appears to be in fine shape. No major
bugs reported. But a Struts 1.3.x is approaching, and i personally
have no idea what--if anything--might need to change on our end to be
compatible. I also don't really have time or interest in pursuing
that.
Concern #2 - The above is without even acknowledging the planned
Struts/Webwork merger for Struts Action 2.0. Webwork at least used to
have Velocity support. i've no idea what the plans are there.
which lead to...
Question #1 - Does anyone else want to take point on the future of
VelocityStruts? I'm content to help support and maintain
VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
out of the game. if no one steps up, VelocityTools 1.3 won't support
Struts 1.3 features and may not even turn out to be compatible. if
that turns out to be true, then it might be time to drop
VelocityStruts (or hand it off to the Struts folks) and move on to a
VelocityTools 2.x without a VelocityStruts component.
then there's also the more positive stuff...
Idea #1 - between what
http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
Tomcat's annoying dependence on commons-logging, and the many
improvements i've made to logging in Velocity 1.5, i am making the
transition from being a big advocate of using commons-logging in the
Velocity world to being rather opposed to it. i want to back
commons-logging use out of VelocityView and GenericTools as soon as we
are able to depend on Velocity 1.5.
Idea #2 - I want to GenericTools to be Configurable via toolbox
parameters. but Configurable is a VelocityView interface. the
three-part package issue has officially gotten in the way. but i
think we can get around it in a very Velocity-ish way: let's
drop/deprecate the ViewTool and Configurable interfaces and, instead,
just use reflection in ViewToolInfo to identify and leverage tools
that have init(Object) or configure(Map) methods. this is one of the
things i have working locally and will hopefully check in soon,
barring strong objections.
Idea #3 - We've talked about adopting Veltag. i definitely have this
itch and have been developing toolbox support for it. i'm well on my
way to completing this, but it means some very big internal changes
for the servlets. too much code was being duplicated between the
improved VelocityViewTag (yeah, i think we should rename it) and
VelocityViewServlet. so i've factored that out into a bare
VelocityView class that has the necessary support for both.
Idea #4 - So-called "standalone" toolbox support
(http://issues.apache.org/jira/browse/VELTOOLS-8). The VelocityView
object above is web-centric, but i agree, it'd be nice to make toolbox
support for non-j2ee Velocity apps easy. i haven't done any work
here, but i'm thinking it will probably require some heavy package
re-organization. it would just be easier to go 2.x and not have to
worry about being B.C.
Idea #5 - Tool use syntax simplification. I've made a fair number of
tweaks along this line a both before and after VelocityTools 1.2 was
released. using the profound ugliness that is JSP syntax (JSTL only
helps a little) has only sharpened my appetite for syntactic elegance.
expect to see more of this from me, and please give feedback or
suggestions in this area.
all of these lead to...
Question #2 - What do you think of these ideas?
Question #3 - Does anyone really want any of these in a VelocityTools
1.3? Or should we just move on to work on a VelocityTools 2?
Question #4 - Are there any other "big" ideas out there for a VelocityTools 2?
then my last and lesser question is...
Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
i want to see support for it in DateTool (or a new tool if need be).
i haven't had time to tackle this myself. has anyone else done this
yet? anyone want to? i'll probably get to it eventually, but as you
can see from the above, i already have bitten off a lot to chew. :)
thanks for listening.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Nathan,
Thanks for offering such a in-depth list of thoughts. I know we all
appreciate the TLC you've given the Velocity Tools project over the years.
I don't have detailed comments, but I wanted to urge you to include Veltags
in the tools distribution. This seems like a nifty little bridge between
Velocity and JSP. It'd be great to see it more integrated.
I don't have strong feelings about commons-logging. Lots of people complain
about it. I've had some issues with Tomcat that were possibly made more
complex by commons-logging. But there's a lot of passion here on both
sides. Follow your heart.
Regarding support for VelocityStruts, it's great that Marino has offered to
jump in. Appreciate your publically asking for help on this one -- it's
tough to support/enhance a project that you're not personally using
regularly. Marino, if you need help or have trouble with this we might want
to fish for additional volunteers on the user list or maybe the Struts list.
Otherwise, my general feeling is to follow these objectives: easy for new
users to get started with servlets, simple API and syntax, and provide
bridges to Struts (and now JSP/possibly other web frameworks).
WILL
On 3/10/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> On 3/10/06, Marinó A. Jónsson <ma...@centrum.is> wrote:
> > Greetings,
> >
> > On fim, 2006-03-09 at 14:28 -0800, Nathan Bubna wrote:
> >
> > > Question #1 - Does anyone else want to take point on the future of
> > > VelocityStruts? I'm content to help support and maintain
> > > VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
> > > out of the game. if no one steps up, VelocityTools 1.3 won't support
> > > Struts 1.3 features and may not even turn out to be compatible. if
> > > that turns out to be true, then it might be time to drop
> > > VelocityStruts (or hand it off to the Struts folks) and move on to a
> > > VelocityTools 2.x without a VelocityStruts component.
> >
> > I am using VelocityStruts v1.2 and would be happy to take the point on
> > VelocityStruts v1.3. I don't see anything in Struts v1.3 that should
> > compromise continued support - on the contrary it seems we will finally
> > get the long awaited ViewContext in the next release - which should make
> > our work a lot easier! So I would like a VelocityTools v1.3 release
> > that supports Struts v1.3 - but I have no thoughts on the Struts Action
> > 2.0 issue.
>
> Excellent! if you can bring us up to speed with Struts 1.3, then i'm
> willing to spruce up VelocityView and GenericTools a bit and push out
> a release.
>
> > > Idea #1 - between what
> > > http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
> > > Tomcat's annoying dependence on commons-logging, and the many
> > > improvements i've made to logging in Velocity 1.5, i am making the
> > > transition from being a big advocate of using commons-logging in the
> > > Velocity world to being rather opposed to it. i want to back
> > > commons-logging use out of VelocityView and GenericTools as soon as we
> > > are able to depend on Velocity 1.5.
> >
> > Interesting ... could you elaborate on that a little? Are you now more
> > of an IoC man like Geir? Do you want further development of SimpleLog?
>
> i dunno. i'm still chewing on this stuff. the
> Tomcat5.5/commons-logging problems were (and still sort of are) a
> major headache that make commons-logging less helpful IMO. i've also
> been seeing more problems with the things like the StaticLog issue out
> in the wild. avoiding those means further loss in usefulness. on the
> other side, the new Log/LogChute stuff in Velocity is much more useful
> than it was. since i'm really more of a practical software developer
> than an idealist software developer (ask me how much i care that
> VelocityView isn't pure-MVC :), the basic reality is that Log/LogChute
> have become pleasant to use and c-l has become less so. and of
> course, one logging adapter is easier than two.
>
> i think c-l still makes sense for VelocityStruts as long as Struts is
> using c-l (though we may want to drop static use of it). but for
> VelocityView and GenericTools, i want to shift to Velocity's adapter
> as soon as is feasible.
>
> > > Question #2 - What do you think of these ideas?
> >
> > They all sound pretty good to me :)
> >
> > > Question #3 - Does anyone really want any of these in a VelocityTools
> > > 1.3? Or should we just move on to work on a VelocityTools 2?
> >
> > Can't say that I'd miss them in v1.3, personally.
>
> sounds fine. i think Ideas #2 and #5 will make appearances in
> VelocityTools 1.3, but i probably won't throw effort after getting the
> others into it.
>
> > > Question #4 - Are there any other "big" ideas out there for a
> VelocityTools 2?
> >
> > Not from me.
> >
> > > then my last and lesser question is...
> > >
> > > Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> > > i want to see support for it in DateTool (or a new tool if need be).
> > > i haven't had time to tackle this myself. has anyone else done this
> > > yet? anyone want to? i'll probably get to it eventually, but as you
> > > can see from the above, i already have bitten off a lot to chew. :)
> >
> > No interest here at this time.
> >
> > cheers,
> > Marinó
> >
> > > thanks for listening.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: [veltools] what next...
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/10/06, Marinó A. Jónsson <ma...@centrum.is> wrote:
> Greetings,
>
> On fim, 2006-03-09 at 14:28 -0800, Nathan Bubna wrote:
>
> > Question #1 - Does anyone else want to take point on the future of
> > VelocityStruts? I'm content to help support and maintain
> > VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
> > out of the game. if no one steps up, VelocityTools 1.3 won't support
> > Struts 1.3 features and may not even turn out to be compatible. if
> > that turns out to be true, then it might be time to drop
> > VelocityStruts (or hand it off to the Struts folks) and move on to a
> > VelocityTools 2.x without a VelocityStruts component.
>
> I am using VelocityStruts v1.2 and would be happy to take the point on
> VelocityStruts v1.3. I don't see anything in Struts v1.3 that should
> compromise continued support - on the contrary it seems we will finally
> get the long awaited ViewContext in the next release - which should make
> our work a lot easier! So I would like a VelocityTools v1.3 release
> that supports Struts v1.3 - but I have no thoughts on the Struts Action
> 2.0 issue.
Excellent! if you can bring us up to speed with Struts 1.3, then i'm
willing to spruce up VelocityView and GenericTools a bit and push out
a release.
> > Idea #1 - between what
> > http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
> > Tomcat's annoying dependence on commons-logging, and the many
> > improvements i've made to logging in Velocity 1.5, i am making the
> > transition from being a big advocate of using commons-logging in the
> > Velocity world to being rather opposed to it. i want to back
> > commons-logging use out of VelocityView and GenericTools as soon as we
> > are able to depend on Velocity 1.5.
>
> Interesting ... could you elaborate on that a little? Are you now more
> of an IoC man like Geir? Do you want further development of SimpleLog?
i dunno. i'm still chewing on this stuff. the
Tomcat5.5/commons-logging problems were (and still sort of are) a
major headache that make commons-logging less helpful IMO. i've also
been seeing more problems with the things like the StaticLog issue out
in the wild. avoiding those means further loss in usefulness. on the
other side, the new Log/LogChute stuff in Velocity is much more useful
than it was. since i'm really more of a practical software developer
than an idealist software developer (ask me how much i care that
VelocityView isn't pure-MVC :), the basic reality is that Log/LogChute
have become pleasant to use and c-l has become less so. and of
course, one logging adapter is easier than two.
i think c-l still makes sense for VelocityStruts as long as Struts is
using c-l (though we may want to drop static use of it). but for
VelocityView and GenericTools, i want to shift to Velocity's adapter
as soon as is feasible.
> > Question #2 - What do you think of these ideas?
>
> They all sound pretty good to me :)
>
> > Question #3 - Does anyone really want any of these in a VelocityTools
> > 1.3? Or should we just move on to work on a VelocityTools 2?
>
> Can't say that I'd miss them in v1.3, personally.
sounds fine. i think Ideas #2 and #5 will make appearances in
VelocityTools 1.3, but i probably won't throw effort after getting the
others into it.
> > Question #4 - Are there any other "big" ideas out there for a VelocityTools 2?
>
> Not from me.
>
> > then my last and lesser question is...
> >
> > Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> > i want to see support for it in DateTool (or a new tool if need be).
> > i haven't had time to tackle this myself. has anyone else done this
> > yet? anyone want to? i'll probably get to it eventually, but as you
> > can see from the above, i already have bitten off a lot to chew. :)
>
> No interest here at this time.
>
> cheers,
> Marinó
>
> > thanks for listening.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Greetings,
On fim, 2006-03-09 at 14:28 -0800, Nathan Bubna wrote:
> Question #1 - Does anyone else want to take point on the future of
> VelocityStruts? I'm content to help support and maintain
> VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
> out of the game. if no one steps up, VelocityTools 1.3 won't support
> Struts 1.3 features and may not even turn out to be compatible. if
> that turns out to be true, then it might be time to drop
> VelocityStruts (or hand it off to the Struts folks) and move on to a
> VelocityTools 2.x without a VelocityStruts component.
I am using VelocityStruts v1.2 and would be happy to take the point on
VelocityStruts v1.3. I don't see anything in Struts v1.3 that should
compromise continued support - on the contrary it seems we will finally
get the long awaited ViewContext in the next release - which should make
our work a lot easier! So I would like a VelocityTools v1.3 release
that supports Struts v1.3 - but I have no thoughts on the Struts Action
2.0 issue.
> Idea #1 - between what
> http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
> Tomcat's annoying dependence on commons-logging, and the many
> improvements i've made to logging in Velocity 1.5, i am making the
> transition from being a big advocate of using commons-logging in the
> Velocity world to being rather opposed to it. i want to back
> commons-logging use out of VelocityView and GenericTools as soon as we
> are able to depend on Velocity 1.5.
Interesting ... could you elaborate on that a little? Are you now more
of an IoC man like Geir? Do you want further development of SimpleLog?
> Question #2 - What do you think of these ideas?
They all sound pretty good to me :)
> Question #3 - Does anyone really want any of these in a VelocityTools
> 1.3? Or should we just move on to work on a VelocityTools 2?
Can't say that I'd miss them in v1.3, personally.
> Question #4 - Are there any other "big" ideas out there for a VelocityTools 2?
Not from me.
> then my last and lesser question is...
>
> Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> i want to see support for it in DateTool (or a new tool if need be).
> i haven't had time to tackle this myself. has anyone else done this
> yet? anyone want to? i'll probably get to it eventually, but as you
> can see from the above, i already have bitten off a lot to chew. :)
No interest here at this time.
cheers,
Marinó
> thanks for listening.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
[...]
>large Struts app in the last six years, I must say that the experience
[...]
Uh, make this "months". As you can see, my mind is already starting
to melt from too much Struts exposure... :-)
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/26/06, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> "Nathan Bubna" <nb...@gmail.com> writes:
>
> [... can't say much about Struts. Even though I've worked on a quite
> large Struts app in the last six years, I must say that the experience
> was just like all the other Struts experiences before. The fact that
> it won out over Turbine is due to the fact that the docs are great and
> it fit nicely into the Sun view of the Java world. The framework
> itself is, well, well, it could be better... ]
>
>
> >Idea #1 - between what
> >http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
> >Tomcat's annoying dependence on commons-logging, and the many
> >improvements i've made to logging in Velocity 1.5, i am making the
> >transition from being a big advocate of using commons-logging in the
> >Velocity world to being rather opposed to it. i want to back
> >commons-logging use out of VelocityView and GenericTools as soon as we
> >are able to depend on Velocity 1.5.
>
> Ah, that is a new twist to the good old "JCL is evil" scheme. Yes,
> I've seen that problem before. The question here is, is VelocityTools
> "application code" or "library code". You probably don't want to back
> out the references but the static modifiers.
>
> However, considering the fact that Spring Framework uses
>
> private static final Log logger = LogFactory.getLog(...)
>
> all over the place, I don't see that problem going away soon. So I
> wouldn't spend too much time thinking about it anyway.
oh, i've already spent far too much time thinking about logging in the
last year. :) and really, this static thing can be just as much a
catch with log4j as jcl. honestly, while the static issue may carry
more theoretic weight, the Tomcat issue and improved practicality of
the new LogChute stuff in Velocity are bigger motivators for me
personally.
> >Idea #4 - So-called "standalone" toolbox support
> >(http://issues.apache.org/jira/browse/VELTOOLS-8). The VelocityView
> >object above is web-centric, but i agree, it'd be nice to make toolbox
> >support for non-j2ee Velocity apps easy. i haven't done any work
> >here, but i'm thinking it will probably require some heavy package
> >re-organization. it would just be easier to go 2.x and not have to
> >worry about being B.C.
>
> yep. +1 here.
>
> [...]
>
> >Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> >i want to see support for it in DateTool (or a new tool if need be).
> >i haven't had time to tackle this myself. has anyone else done this
> >yet? anyone want to? i'll probably get to it eventually, but as you
> >can see from the above, i already have bitten off a lot to chew. :)
>
> Uh, yet _another_ wheel re-invention? The problem with all these great libraries is, that most people either
>
> a) don't know about them
> b) can't use them in their projects because they have to deal with 400kLOC of
> existing code
> c) are happy with what is in the JDK.
>
> Personally, I'd like to have stuff like that as an add-on. Best as a
> pluggable implementation. If there is one lesson to learn from Spring
> Framework then it is that "being flexible" is the way to go.
ok, we can just do it as a subclass of DateTool, so if you don't use
it, it won't affect you or require anything of you. the whole toolbox
thing makes all of our tools intrinsically pluggable. :) so having it
as an "add-on" really only saves a few kb for those who don't use it,
but makes it a lot tougher for those who want it.
and really, the apps we develop for work are seriously date-driven.
the DateTool is one of my favorite parts of veltools. since i've been
working on a jsp/jstl app for the last few months, i've been really
missing it. i'm sick of tags.
> Best regards
> Henning
>
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> Social behaviour: Bavarians can be extremely egalitarian and folksy.
> -- http://en.wikipedia.org/wiki/Bavaria
> Most Franconians do not like to be called Bavarians.
> -- http://en.wikipedia.org/wiki/Franconia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <nb...@gmail.com> writes:
[... can't say much about Struts. Even though I've worked on a quite
large Struts app in the last six years, I must say that the experience
was just like all the other Struts experiences before. The fact that
it won out over Turbine is due to the fact that the docs are great and
it fit nicely into the Sun view of the Java world. The framework
itself is, well, well, it could be better... ]
>Idea #1 - between what
>http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about,
>Tomcat's annoying dependence on commons-logging, and the many
>improvements i've made to logging in Velocity 1.5, i am making the
>transition from being a big advocate of using commons-logging in the
>Velocity world to being rather opposed to it. i want to back
>commons-logging use out of VelocityView and GenericTools as soon as we
>are able to depend on Velocity 1.5.
Ah, that is a new twist to the good old "JCL is evil" scheme. Yes,
I've seen that problem before. The question here is, is VelocityTools
"application code" or "library code". You probably don't want to back
out the references but the static modifiers.
However, considering the fact that Spring Framework uses
private static final Log logger = LogFactory.getLog(...)
all over the place, I don't see that problem going away soon. So I
wouldn't spend too much time thinking about it anyway.
>Idea #4 - So-called "standalone" toolbox support
>(http://issues.apache.org/jira/browse/VELTOOLS-8). The VelocityView
>object above is web-centric, but i agree, it'd be nice to make toolbox
>support for non-j2ee Velocity apps easy. i haven't done any work
>here, but i'm thinking it will probably require some heavy package
>re-organization. it would just be easier to go 2.x and not have to
>worry about being B.C.
yep. +1 here.
[...]
>Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
>i want to see support for it in DateTool (or a new tool if need be).
>i haven't had time to tackle this myself. has anyone else done this
>yet? anyone want to? i'll probably get to it eventually, but as you
>can see from the above, i already have bitten off a lot to chew. :)
Uh, yet _another_ wheel re-invention? The problem with all these great libraries is, that most people either
a) don't know about them
b) can't use them in their projects because they have to deal with 400kLOC of
existing code
c) are happy with what is in the JDK.
Personally, I'd like to have stuff like that as an add-on. Best as a
pluggable implementation. If there is one lesson to learn from Spring
Framework then it is that "being flexible" is the way to go.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/10/06, Claude Brisson <cl...@renegat.net> wrote:
> Le vendredi 10 mars 2006 à 08:04 -0800, Nathan Bubna a écrit :
> > well, if you remember, the whole project was birthed out of the desire
> > to use Velocity with Struts. :)
>
> We evolved from monkeys after all...
:)
> > > What about tools pooling ?
> >
> > that's still in the back of my mind. i got pretty far along the path
> > of implementing this a few years ago in a local tree, but it quickly
> > became clear that i couldn't make it B.C. or work for GenericTools
> > without just going to 2.x. i've also been demotivated by the
> > improvements to garbage collection and instantiation of objects in
> > newer JVMs. still, if we're going to work on 2.x, i'm willing to dig
> > up that old code. it should be easier now, especially with idea #2.
> > if/when we get to this, are you willing to help?
>
> Sure!
>
> > > Also, do you remember my proposal to have regexp scopes for tools? The
> > > idea was that regexp scopes are thinner than the request scope: tools
> > > are instanciated only if the URL matches the regexp. I'm quite sure that
> > > the performance issue is not that great for compiled regexps.
> >
> > oh, yeah. i totally forgot about that. it's a pretty nifty idea.
> > i'll keep it in mind, so i don't make any changes that would make that
> > really hard to do. but again, it's not a big itch for me. help would
> > be great. :)
>
> Of course. Is it useful to code it with the actual codebase or should I
> wait for some changes of yours?
on both this and the pooling, give me a little time to create a
VELTOOLS_2 branch and start checking in some of the hacks i've been
making. especially the Idea #2 stuff and the new VelocityView stuff
that i've pulled out of the VVS.
> > > Otherwise - VelocityView is a minimal web framework - as such, it deals
> > > with some problematics that are more linked to standard webapp concerns
> > > than to Velocity itself. So my question: To be able to provide a
> > > ready-to-use webapp, should the view tools adress standard web
> > > problematics like validation, authentication, and the like?
> >
> > sorry, but i have no plans to turn VelocityView into a web framework.
> > i'm actually mildly opposed to that; i like using it as just a view
> > layer. there are others that solve the other pieces and integrate
> > with VelocityView just fine. if you or others want to build a
> > framework around the VelocityView layer, that's fine, but i think
> > it'll have to be a separate project.
>
> That's not really what I meant - I really like the "bottom-up" approach
> of the tools and its open spirit, so better keep it instead of proposing
> yet another framework... I was rather thinking to some way of gathering
> some standard patterns a la "build your own framework", like having a
> minimalist ActionFilter or AuthenticationFilter along with the
> VelocityViewServlet but maybe you're right that it should be separate. I
> still hope we can elaborate on this subject around here.
sure. far be it from me to stifle such an effort. i'm even a bit
interested in it. just know that my intention is to keep VelocityView
as exactly that--a Velocity-based view layer. so, any
controller/model stuff will probably have to be a separate project.
>
> Claude
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Claude Brisson <cl...@renegat.net>.
Le vendredi 10 mars 2006 à 08:04 -0800, Nathan Bubna a écrit :
> well, if you remember, the whole project was birthed out of the desire
> to use Velocity with Struts. :)
We evolved from monkeys after all...
> > What about tools pooling ?
>
> that's still in the back of my mind. i got pretty far along the path
> of implementing this a few years ago in a local tree, but it quickly
> became clear that i couldn't make it B.C. or work for GenericTools
> without just going to 2.x. i've also been demotivated by the
> improvements to garbage collection and instantiation of objects in
> newer JVMs. still, if we're going to work on 2.x, i'm willing to dig
> up that old code. it should be easier now, especially with idea #2.
> if/when we get to this, are you willing to help?
Sure!
> > Also, do you remember my proposal to have regexp scopes for tools? The
> > idea was that regexp scopes are thinner than the request scope: tools
> > are instanciated only if the URL matches the regexp. I'm quite sure that
> > the performance issue is not that great for compiled regexps.
>
> oh, yeah. i totally forgot about that. it's a pretty nifty idea.
> i'll keep it in mind, so i don't make any changes that would make that
> really hard to do. but again, it's not a big itch for me. help would
> be great. :)
Of course. Is it useful to code it with the actual codebase or should I
wait for some changes of yours?
> > Otherwise - VelocityView is a minimal web framework - as such, it deals
> > with some problematics that are more linked to standard webapp concerns
> > than to Velocity itself. So my question: To be able to provide a
> > ready-to-use webapp, should the view tools adress standard web
> > problematics like validation, authentication, and the like?
>
> sorry, but i have no plans to turn VelocityView into a web framework.
> i'm actually mildly opposed to that; i like using it as just a view
> layer. there are others that solve the other pieces and integrate
> with VelocityView just fine. if you or others want to build a
> framework around the VelocityView layer, that's fine, but i think
> it'll have to be a separate project.
That's not really what I meant - I really like the "bottom-up" approach
of the tools and its open spirit, so better keep it instead of proposing
yet another framework... I was rather thinking to some way of gathering
some standard patterns a la "build your own framework", like having a
minimalist ActionFilter or AuthenticationFilter along with the
VelocityViewServlet but maybe you're right that it should be separate. I
still hope we can elaborate on this subject around here.
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/10/06, Claude Brisson <cl...@renegat.net> wrote:
> Hello Nathan
>
> Le jeudi 09 mars 2006 à 14:28 -0800, Nathan Bubna a écrit :
> > Question #1 - Does anyone else want to take point on the future of
> > VelocityStruts? I'm content to help support and maintain
> > VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
> > out of the game. if no one steps up, VelocityTools 1.3 won't support
> > Struts 1.3 features and may not even turn out to be compatible. if
> > that turns out to be true, then it might be time to drop
> > VelocityStruts (or hand it off to the Struts folks) and move on to a
> > VelocityTools 2.x without a VelocityStruts component.
>
> I'm not using Struts nor VelocityStruts, so of course I'm in favour of a
> VelocityTools 2.x. I never used Struts since it always seemed quite
> bloated to me, and that is the exact reason why I like the lightweight
> aspects of VelocityTools. So I've always seen VelocityStruts as a very
> paradoxal entity...
well, if you remember, the whole project was birthed out of the desire
to use Velocity with Struts. :)
> > Question #2 - What do you think of these ideas?
>
> Idea #1 - commons-logging: I'm quite neutral on this.
>
> Idea #2 - reflection: Great ! And backward compatible, by the way.
yep!
> Idea #3 - veltag: As long as veltag tools don't pollute too much Generic
> and View tools! I'm not using it either.
not to worry, the tag should use tools just the same as the servlet.
> Idea #4 - standalone toolbox: if it's easier for 2.x, ok, but I thought
> there already was a patch for it?!
there is, but the implementation is a not really what i'm
half-thinking about. i'd actually like it to be a little less
"standalone" and overlap/serve-as-a-base for the other toolbox
support. but i can't really be sure there until i dig into
implementing it a little more.
> Idea #5 - syntax simplification: it is always great.
>
> > Question #3 - Does anyone really want any of these in a VelocityTools
> > 1.3? Or should we just move on to work on a VelocityTools 2?
>
> AFAIAC, 2.x is ok.
>
> > Question #4 - Are there any other "big" ideas out there for a VelocityTools 2?
>
> What about tools pooling ?
that's still in the back of my mind. i got pretty far along the path
of implementing this a few years ago in a local tree, but it quickly
became clear that i couldn't make it B.C. or work for GenericTools
without just going to 2.x. i've also been demotivated by the
improvements to garbage collection and instantiation of objects in
newer JVMs. still, if we're going to work on 2.x, i'm willing to dig
up that old code. it should be easier now, especially with idea #2.
if/when we get to this, are you willing to help?
> Also, do you remember my proposal to have regexp scopes for tools? The
> idea was that regexp scopes are thinner than the request scope: tools
> are instanciated only if the URL matches the regexp. I'm quite sure that
> the performance issue is not that great for compiled regexps.
oh, yeah. i totally forgot about that. it's a pretty nifty idea.
i'll keep it in mind, so i don't make any changes that would make that
really hard to do. but again, it's not a big itch for me. help would
be great. :)
> Otherwise - VelocityView is a minimal web framework - as such, it deals
> with some problematics that are more linked to standard webapp concerns
> than to Velocity itself. So my question: To be able to provide a
> ready-to-use webapp, should the view tools adress standard web
> problematics like validation, authentication, and the like?
sorry, but i have no plans to turn VelocityView into a web framework.
i'm actually mildly opposed to that; i like using it as just a view
layer. there are others that solve the other pieces and integrate
with VelocityView just fine. if you or others want to build a
framework around the VelocityView layer, that's fine, but i think
it'll have to be a separate project.
> > then my last and lesser question is...
> >
> > Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> > i want to see support for it in DateTool (or a new tool if need be).
> > i haven't had time to tackle this myself. has anyone else done this
> > yet? anyone want to? i'll probably get to it eventually, but as you
> > can see from the above, i already have bitten off a lot to chew. :)
>
> Interesting.
>
>
> Cheers,
>
> Claude
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] what next...
Posted by Claude Brisson <cl...@renegat.net>.
Hello Nathan
Le jeudi 09 mars 2006 à 14:28 -0800, Nathan Bubna a écrit :
> Question #1 - Does anyone else want to take point on the future of
> VelocityStruts? I'm content to help support and maintain
> VelocityStruts 1.2 for a while, but beyond that, i think i need to bow
> out of the game. if no one steps up, VelocityTools 1.3 won't support
> Struts 1.3 features and may not even turn out to be compatible. if
> that turns out to be true, then it might be time to drop
> VelocityStruts (or hand it off to the Struts folks) and move on to a
> VelocityTools 2.x without a VelocityStruts component.
I'm not using Struts nor VelocityStruts, so of course I'm in favour of a
VelocityTools 2.x. I never used Struts since it always seemed quite
bloated to me, and that is the exact reason why I like the lightweight
aspects of VelocityTools. So I've always seen VelocityStruts as a very
paradoxal entity...
> Question #2 - What do you think of these ideas?
Idea #1 - commons-logging: I'm quite neutral on this.
Idea #2 - reflection: Great ! And backward compatible, by the way.
Idea #3 - veltag: As long as veltag tools don't pollute too much Generic
and View tools! I'm not using it either.
Idea #4 - standalone toolbox: if it's easier for 2.x, ok, but I thought
there already was a patch for it?!
Idea #5 - syntax simplification: it is always great.
> Question #3 - Does anyone really want any of these in a VelocityTools
> 1.3? Or should we just move on to work on a VelocityTools 2?
AFAIAC, 2.x is ok.
> Question #4 - Are there any other "big" ideas out there for a VelocityTools 2?
What about tools pooling ?
Also, do you remember my proposal to have regexp scopes for tools? The
idea was that regexp scopes are thinner than the request scope: tools
are instanciated only if the URL matches the regexp. I'm quite sure that
the performance issue is not that great for compiled regexps.
Otherwise - VelocityView is a minimal web framework - as such, it deals
with some problematics that are more linked to standard webapp concerns
than to Velocity itself. So my question: To be able to provide a
ready-to-use webapp, should the view tools adress standard web
problematics like validation, authentication, and the like?
> then my last and lesser question is...
>
> Question #5 - joda-time (http://joda-time.sourceforge.net/) is great.
> i want to see support for it in DateTool (or a new tool if need be).
> i haven't had time to tackle this myself. has anyone else done this
> yet? anyone want to? i'll probably get to it eventually, but as you
> can see from the above, i already have bitten off a lot to chew. :)
Interesting.
Cheers,
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org