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/02/12 04:22:07 UTC
[veltools] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Nathan said:
> I've been collecting some issues/suggestions for a little while now. I'll
> be posting it to the list soon (tomorrow if i snag the time), so keep an
eye
> out here. I may also throw it in CVS so we have some way of keeping track
> of these things (since we don't presently have a place to track issues for
> this project in bugzilla).
I've checked in a STATUS document to track issues and proposed features for
jakarta-velocity-tools. it's something of a collection of things discussed
both recently and long ago. you can find it at:
http://cvs.apache.org/viewcvs/jakarta-velocity-tools/STATUS?rev=1.2&content-
type=text/vnd.viewcvs-markup
this is not, of course, a promise or contract, but is simply meant to help
us keep track of things and let people get a feel for where things seem to
be headed.
hopefully at some point, we'll find a real home of our own in bugzilla for
some of these things. i have not the karma to make that for us.
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] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Gabriel Sidler <si...@teamup.com>.
Tim Colson wrote:
>>the other thing we need is docs. (Tim is already helping out
>>here too.)
>>
>
> Say - speaking of doc things... Where's Gabe and others to weigh in on
> the naming convention and tools/tools consolidation proposal? :-)
Sorry for being quite so long. I just realized that I had misconfigured
my mail filter for the velocity-dev list when I moved to a new mail client
last week. I didn't see any of last weeks discussions up until now.
I need a day or so to catch up.
Gabe
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [veltools] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Tim Colson <tc...@cisco.com>.
> the other thing we need is docs. (Tim is already helping out
> here too.)
Say - speaking of doc things... Where's Gabe and others to weigh in on
the naming convention and tools/tools consolidation proposal? :-)
I'd like to fix the docs as appropriate and then start submitting diffs
as soon as possible. :-)
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] VelocityViewServlet internal stuff
Posted by Anthony Kay <aw...@yahoo.com>.
> or so, but in the meantime, feel free to try it out yourself and let
> us know
> if it works. if it does, send a patch and i'll give it a go. code
> is a lot
> easier (and less time-consuming) for me to evaluate than suggested
> plans
> are. :)
Sure, I understand that. I was just running it by to see if anybody
was going to pop up with "that won't work because..." since I'm
pretty new to the code base, and might be suggesting something
that someone has immediate advice on.
I will give the suggested implementation a go, and build at least one
example, and perhaps even a test case or two.
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] VelocityViewServlet internal stuff
Posted by Nathan Bubna <na...@esha.com>.
Anthony said:
> 1) Why is there a wrapper (VelocityStrutsServletAppContext)
> to "safely" pass ServletContext to other parts of the app?
> It is being passed by reference anyway, and a copy is
> not being made, so I see no extra safety in this. If it is to
> avoid someone putting something wierd in its place for a later
> app module to find, can't the same thing happen with the wrapper?
> IMHO, it would be advantageous to store the
> ServletContext itself under a standardized key, which would
> then allow a custom resource loader or logger to find it
> (if it needed it).
you know, i've never really looked at this stuff before. when i don't write
it myself or have any problems with it, i just tend to glaze over sometimes.
:) anyway, yeah, at first glance, i don't see why the wrapper is
needed/useful either (and that attribute key should really be a constant
somewhere!).
Geir? are you out there? i'm assuming there's a reason it was done this
way. is there still a reason?
> 2) On logging. It looks as if the user need only supply a derivation
> of LogSystem classname in a property, and then something like
> the following might work:
>
> a. Put ServletContext under a well-known key (see (1))
> b. Get the logger class name from properties
> b.2 default to current ServletLogger if not specified
> c. Load the class and instantiate (no-arg constructor)
> c.2 insure object is instanceof LogSystem
> c.2 Class can get ServletContext from well-known key
> d. Put LogSystem instance into Velocity
>
> 3) Resource loader. Correct me if I'm wrong, but you want the
> resource loader to be configurable so that someone can do
> something wiggy like load templates from a database or
> network server? If the ServletContext is under a well-known
> key, a solution similar to the logging one I just proposed
> would probably be just fine, no?
these sound reasonable, but as i said, i haven't looked into the
code/problem carefully. i may try to look thru this myself in the next week
or so, but in the meantime, feel free to try it out yourself and let us know
if it works. if it does, send a patch and i'll give it a go. code is a lot
easier (and less time-consuming) for me to evaluate than suggested plans
are. :)
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] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Anthony Kay <aw...@yahoo.com>.
Nathan,
I looked into the source. Let me bounce this off of you.
1) Why is there a wrapper (VelocityStrutsServletAppContext)
to "safely" pass ServletContext to other parts of the app?
It is being passed by reference anyway, and a copy is
not being made, so I see no extra safety in this. If it is to
avoid someone putting something wierd in its place for a later
app module to find, can't the same thing happen with the wrapper?
IMHO, it would be advantageous to store the
ServletContext itself under a standardized key, which would
then allow a custom resource loader or logger to find it
(if it needed it).
2) On logging. It looks as if the user need only supply a derivation
of LogSystem classname in a property, and then something like
the following might work:
a. Put ServletContext under a well-known key (see (1))
b. Get the logger class name from properties
b.2 default to current ServletLogger if not specified
c. Load the class and instantiate (no-arg constructor)
c.2 insure object is instanceof LogSystem
c.2 Class can get ServletContext from well-known key
d. Put LogSystem instance into Velocity
3) Resource loader. Correct me if I'm wrong, but you want the
resource loader to be configurable so that someone can do
something wiggy like load templates from a database or
network server? If the ServletContext is under a well-known
key, a solution similar to the logging one I just proposed
would probably be just fine, no?
- Tony
--- Nathan Bubna <na...@esha.com> wrote:
> Anthony said:
> ...
> > Nathan said:
> > > if you're really looking for something to dig into, the current
> > > configuration issue (hard-coded, non-overwritable logger and
> resource
> > > loader) might be a good one for you. i've looked at it a bit,
> and
> > > i've yet
> > > to see a clean solution for it. if you want to take a shot, i
> think
> > > that'd
> > > be great place to start.
> >
> > Could you give me a little better direction than this? Are you
> talking
> > about issues with the stand-alone Velocity or the Tools?
>
> i was referring to the "Known Issues/Bugs" section in the STATUS
> document
> for the tools subproject. in particular, the first listed "issue."
>
> if you're interested in digging into this, the first place you'll
> want to
> look is in the initVelocity() method of the VelocityViewServlet.
> there the
> velocity.properties file is loaded and the log system and resource
> loader
> are explicitly set (in hard-coded fashion, regardless of the
> velocity.properties that were loaded). this is not really a
> "showstopper,"
> and if it ends up requiring some more drastic changes, i may be
> willing to
> support a 1.0 release without dealing with this. but, we need to at
> least
> take a shot at 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
>
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Nathan Bubna <na...@esha.com>.
Anthony said:
...
> Nathan said:
> > if you're really looking for something to dig into, the current
> > configuration issue (hard-coded, non-overwritable logger and resource
> > loader) might be a good one for you. i've looked at it a bit, and
> > i've yet
> > to see a clean solution for it. if you want to take a shot, i think
> > that'd
> > be great place to start.
>
> Could you give me a little better direction than this? Are you talking
> about issues with the stand-alone Velocity or the Tools?
i was referring to the "Known Issues/Bugs" section in the STATUS document
for the tools subproject. in particular, the first listed "issue."
if you're interested in digging into this, the first place you'll want to
look is in the initVelocity() method of the VelocityViewServlet. there the
velocity.properties file is loaded and the log system and resource loader
are explicitly set (in hard-coded fashion, regardless of the
velocity.properties that were loaded). this is not really a "showstopper,"
and if it ends up requiring some more drastic changes, i may be willing to
support a 1.0 release without dealing with this. but, we need to at least
take a shot at 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: [contribution] ListTool
Posted by Nathan Bubna <na...@esha.com>.
Otto said:
> I'd like to contribute a new tool to the Velocity project.
> I wrote this tool because I needed a simple way to generate
> HTML dropdowns given Lists of business objects (I use it
> with Torque)
your willingness to contribute is appreciated, but generating HTML from
hardcoded java is a bit of a no-no around here. :)
these sorts of things are far better done as Velocimacros IMHO. (which, by
the way, we will hopefully begin collecting in the velocity-tools project to
form a core library of sorts)
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
[contribution] ListTool
Posted by Otto von Wachter <vo...@yahoo.com>.
I'd like to contribute a new tool to the Velocity project.
I wrote this tool because I needed a simple way to generate
HTML dropdowns given Lists of business objects (I use it
with Torque)
Along with the tool there's a simple interface that for a
"value/description getter".
Here's an example of how this tool can be used:
<p>select an address: </p>
#set ($addrs = $addrPeer.doSelectAll())
#set ($selAddr = $form.Address)
#if (!$selAddr) #set($selAddr = "") #end
##I do this because I'm having trouble passing a "null"
object in velocity
$listTool.getDropdown($addrs, $addrPeer.AddressVDGetter,
$selAddr, "address")
This assumes that the peer class has a static instance of a
ValueDescriptionGetter (which can be implemented as an
anonymous class).
I hope this is a useful contribution :)
Regards,
Otto
Re: [veltools] documentation help
Posted by Nathan Bubna <na...@esha.com>.
Tim said:
...
> Don't know if you've caught the threads over the past week regarding the
> doc changes I whiteboarded, some naming conventions, and possibly
> rolling tools/tools up into the tools/view tree.
there's also the velocimacro library proposal out there.
> Please have a look if you haven't, would be great to hear some more
> feedback on that stuff from somebody other than Nathan and myself. :-)
maybe we should make some noise about whitespace or float support to liven
things up. ;-)
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] documentation help
Posted by Nathan Bubna <na...@esha.com>.
Anthony said:
...
> VelocityViewServlet defines a constant on line 132 that is
> never used, and has yet another value for it.
heh. i'm tired enough for that to be strangely entertaining. :)
the irrelevant line has been duly excised.
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] documentation help
Posted by Anthony Kay <aw...@yahoo.com>.
Hey Tim,
--- Tim Colson <tc...@cisco.com> wrote:
> Howdy Tony -
>
> > This is one of the things I have been contributing to in Struts
> when
> > I have the time. I'm a fair word smith. I'd be glad to help Tim
> > if he needs it (I have no pride issues with just proofreading if
> > that would help).
>
> Don't know if you've caught the threads over the past week regarding
> the
> doc changes I whiteboarded, some naming conventions, and possibly
> rolling tools/tools up into the tools/view tree.
No, I missed them. I was concentrating on other things :-) I will have
to go back through the archive.
>
> Please have a look if you haven't, would be great to hear some more
> feedback on that stuff from somebody other than Nathan and myself.
> :-)
ASAP
>
> Also, another set of eyes looking over the whiteboarded stuff I did
> would be really great!
> http://crufty.happysearch.com/velocity/tools/docs/
Do you have a set of diffs that you could drop to me, perhaps just
by direct E-Mail. I'm can see some of what you've changed, but
diffs would make it easier to comment. I do like your diagram
in the StrutsVelocity section. Oh, and on the configuration file
(view/docs/index.html); the web.xml sample is still using the
"properties" param-name for the location of the properties file.
According to the source, that is deprecated (see
VelocityServlet.java:176). It is a bit confusing, in that
VelocityViewServlet defines a constant on line 132 that is
never used, and has yet another value for it.
>
> There are some points Nathan brought up regarding Tool configuration
> options, and some javadoc that might have wisdom worth lifting up
> into
> the documentation. I haven't had a chance to dive into that stuff yet
> myself.
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [veltools] documentation help
Posted by Tim Colson <tc...@cisco.com>.
Howdy Tony -
> > the other thing we need is docs. (Tim is already helping out here
> > too.)
>
> This is one of the things I have been contributing to in Struts when
> I have the time. I'm a fair word smith. I'd be glad to help Tim
> if he needs it (I have no pride issues with just proofreading if
> that would help).
Don't know if you've caught the threads over the past week regarding the
doc changes I whiteboarded, some naming conventions, and possibly
rolling tools/tools up into the tools/view tree.
Please have a look if you haven't, would be great to hear some more
feedback on that stuff from somebody other than Nathan and myself. :-)
Also, another set of eyes looking over the whiteboarded stuff I did
would be really great!
http://crufty.happysearch.com/velocity/tools/docs/
There are some points Nathan brought up regarding Tool configuration
options, and some javadoc that might have wisdom worth lifting up into
the documentation. I haven't had a chance to dive into that stuff yet
myself.
As soon as there is a concensus on the naming and the tools/tools tree,
I'll update my whiteboard and then start sending patch files via
Bugzilla.
Waiting for Nathan to give a thumbs-up before I do that.
Thanks!
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Anthony Kay <aw...@yahoo.com>.
--- Nathan Bubna <na...@esha.com> wrote:
> ...
> highest priority right now would have to be documentation and the
> currently
> known "issues." i'm almost done cleaning up the inconsistent logging
> in the
> tools, so don't bother yourself with that.
>
> if you're really looking for something to dig into, the current
> configuration issue (hard-coded, non-overwritable logger and resource
> loader) might be a good one for you. i've looked at it a bit, and
> i've yet
> to see a clean solution for it. if you want to take a shot, i think
> that'd
> be great place to start.
Could you give me a little better direction than this? Are you talking
about issues with the stand-alone Velocity or the Tools? I'd be glad
to dig into the source of whatever, since as you say the 1.1 stuff is
not a feasible priority right now, but could you name the main classes
you are concerned about here? I'm reasonably new to both Struts and
Velocity, so I have double learning duty here...
>
> the other thing we need is docs. (Tim is already helping out here
> too.)
This is one of the things I have been contributing to in Struts when
I have the time. I'm a fair word smith. I'd be glad to help Tim
if he needs it (I have no pride issues with just proofreading if
that would help).
- Tony
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Nathan Bubna <na...@esha.com>.
Anthony said:
...
> On the Struts 1.1 stuff:
>
> Did you ever get the 1.1 patches to Velicity-Struts
> that Ted mentioned having? It looks like the external
> view layer that I want to work on in Struts may make it
> into 1.2, but the 1.1 patches, if they already exist
> even in partial form would be a nice starting point.
Ted threw his patches in bugzilla, so yes, i got them. I had some feedback
for him on those i had a chance to look through, but i haven't seen a
response from him on those yet.
Oh, and i did see you proposal/request on struts-dev. it sounds great to
me. hopefully that'll get into 1.2 (which we all pray won't take as long as
1.1).
> I still haven't had the time to properly study the Struts
> features that I do not use. I am going to try to do that
> this week, so perhaps I will be of some use on some of
> these proposals soon.
That's a major hold-up for me as well. Many of the big new features in 1.1
are not things i use. so i'm not prone to spend time learning them and
integrating them.
> Any preference? Realize that I'm still coming up to speed,
> so high priority items are not in my future :o)
highest priority right now would have to be documentation and the currently
known "issues." i'm almost done cleaning up the inconsistent logging in the
tools, so don't bother yourself with that.
if you're really looking for something to dig into, the current
configuration issue (hard-coded, non-overwritable logger and resource
loader) might be a good one for you. i've looked at it a bit, and i've yet
to see a clean solution for it. if you want to take a shot, i think that'd
be great place to start.
the other thing we need is docs. (Tim is already helping out here too.) i
know you're itching to get going on Struts 1.1 stuff, but first what we
really need is to get these issues and docs done, then release a
velocity-tools 1.0 for those still tied to Struts 1.0. at that point, a
Struts 1.1 release will probably be out and we can start implementing
support for it in CVS head.
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] STATUS Was: Re: Offer to Help with Velocity Tools for Struts 1.1
Posted by Anthony Kay <aw...@yahoo.com>.
--- Nathan Bubna <na...@esha.com> wrote:
>
> I've checked in a STATUS document to track issues and proposed
> features for
> jakarta-velocity-tools. it's something of a collection of things
> discussed
> both recently and long ago. you can find it at:
>
>
http://cvs.apache.org/viewcvs/jakarta-velocity-tools/STATUS?rev=1.2&content-
> type=text/vnd.viewcvs-markup
>
> this is not, of course, a promise or contract, but is simply meant to
> help
> us keep track of things and let people get a feel for where things
> seem to
> be headed.
The status document looks good Nathan.
On the Struts 1.1 stuff:
Did you ever get the 1.1 patches to Velicity-Struts
that Ted mentioned having? It looks like the external
view layer that I want to work on in Struts may make it
into 1.2, but the 1.1 patches, if they already exist
even in partial form would be a nice starting point.
I still haven't had the time to properly study the Struts
features that I do not use. I am going to try to do that
this week, so perhaps I will be of some use on some of
these proposals soon.
Any preference? Realize that I'm still coming up to speed,
so high priority items are not in my future :o)
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org