[...]
> > a lot of what MessageTool does is *already* duplicated in the
> > vel-struts package. both StrutsHtmlTool and StrutsBeanTool have similar
> > code offering message resource access. and IMO both classes do it
poorly.
> > so my recommendation would be to completely pull those portions out.
>
> Nathan,
> most of the code in the tools was pulled right from the Struts code
> base.
hmm. but, where it came from seems beside the point. it doesn't excuse poor
organization and needless redundancy.
[..]
> Can you be more specific about how you feel it should be improved?
well i think the MessageTool class i wrote is a fairly specific example, but
i don't think we can get into many specifics if we don't even agree on the
general direction. also, i'm fairly new to Struts so i'm still not fully
versed in its API. that makes it hard to get into many specifics. what i
do know is that in the process of setting up a struts/velocity app, i looked
at the vel-struts package, tried it out a bit, and found it unintuitive and
unwieldy. so i wrote my own tools to do it better. so, you need to know
that while it may feel ok to experienced struts/jsp developers as is, as a
newbie, my impression was almost entirely negative.
[snip]
> Your impression is right. In a first phase we are planning to provide
approx.
> equivalent support for Struts in Velocity as there is support for Struts
in
> JSP. This includes mainly support for access to resources of the Struts
> framework but does not include the more HTML-ish tags like the form tags.
> And yes, currently the context tools are organized and named similarly to
> the corresponding JSP custom tags. This is on purpose and the reasons are
> the following:
and again i say, that may be fine for jsp users looking to switch, but it's
a pain for those starting clean. equivalent functionality doesn't require
equivalent code. and i think that's aiming low. i would be surprised if we
weren't able to wring superior functionality from struts/velocity.
> - Struts developers should be able to communicate with each other
independent
> of the view technology they use. This would be difficult if Velocity has a
> completely different view API.
the view is already *drastically* different! velocity and jsp syntaxes have
very little in common. when changing the view technology, it seems entirely
appropriate to me to change the 'view API.' i think trying to write the
tools so you can make them and your templates mimic a completely different
syntax is a really bad idea that will result in awkward and unwieldy code.
IMO maintaining some slight superficial similarity in the templates is not
reason enough alone to hold to the current direction.
> - I feel it would be quite arrogant to come in and redesign the entire
view
> API that has been developed and used successfully by very many people. I
> believe it is more appropriate to match first what is there and then build
> on it.
match what is there? in using velocity, it is my express purpose to avoid
matching jsp and taglibs. i fully understand many people use jsp/struts
successfully, but that doesn't mean it can't be done better!
> - A similarly structured view API will allow Velocity users to work with
> all the existing tutorials, users guide, examples, etc.
this is true. but i'm a newcomer to struts and i got on fine w/o using the
current vel-struts tools. also, i would hope the goal is to eventually have
examples and documentation for Velocity/Struts specifically. again, this
may be of slight benefit now, but there is no long run benefit.
> - Finally it will help existing Struts developers to make the move to
Velocity
true. but it will not help Struts newbies who wish to use Velocity. and
again, there is already enough difference between jsp+taglibs and
velocity+tools that i don't think the slight benefit is worth the cost.
> I agree view you that the view API can be improved and it is my strong
> believe that we should work on a better APIs. But the base should really
> be something that is roughly comparable what exists today in the Struts
world.
> Does that make sense to you?
yes. and i disagree. :-)
[snip]
> Well, you haven't been very specific about what is wrong with the current
> approach. More specific points would help me. I'll have a look at your
code
> and probably understand better.
please do. i think it may show you how much simpler and cleaner it can be.
after all, why do such things as
$html.isMessage('foo') or $html.getMessage('foo')
when
$msg.exists('foo') or $msg.foo
is just as easy to understand and so much nicer? and why combine disparate
things such as link and message resource functions? and for crying out loud,
'StrutsHtmlTool'!? it is my firm belief that NO html should be found within
velocity context tools. consider me immovably biased against any tool that
outputs markup or has 'html' in the name.
now, of course i haven't fully matched the functionality of jsp taglibs yet
either, but my tools are well on their way. they already have most of the
functionality of yours and some extra to boot. and besides, with velocity,
the logic tags are needless and anything that outputs html is a bad idea, so
those tags can be ignored(as i think you guys already plan to). also, i
believe velocity/context tools is a more powerful and pleasant method and
should easily surpass the taglibs in ease of use and functionality.
> But, I believe that the right first step is
> not to overthrow the view API but to match what is there today on the
> JSP world and build on that.
'to each their own' i suppose. as for me, i think that is needless and
unwise. if we have to agree to disagree, so be it. you don't have to use
my code if you don't want and i don't have to use yours. no hard feelings,
that's just the way it goes sometimes.
> Fortunately the toolbox support will allow us to
> easily replace one tools by another tool. So nothing is written in stone.
true, but it will be much easier to start good habits now, rather than later
when other people become dependent on your code and documentation.
[snip]
take a look at my code and give it a try (esp. MessageTool and LinkTool).
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
