On 2/12/02 8:10 PM, "Nathan Bubna" <[EMAIL PROTECTED]> wrote:
> [...]
>>> 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.
"needless redundancy" is redundant, isn't it?
:)
I guess it isn't. Attempt at a joke.
Time out. Lets be productive about this...
>
> [..]
>> 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.
Ok - that's a subjective assessment so we have to accept that. It would be
nice to get one example though - something that you expected that wasn't
there, maybe the first steps you tried to take...
At worst, we can simply write better docs...
>
> [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.
Yep. We should be able to do superior stuff, but we also should make it easy
to connect the dots from the banging of rocks the JSP users have to do now,
to where we end up (which should include fire the wheel...)
So I think we have to prepared to serve both groups - lets face it - getting
the JSP people over to use Velocity is going to be a Good Thing� for
Velocity and the community.
>
>> - 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.'
Yes. The concepts have to be similar, and the API for each view will by
definition be different. But should do the same thing.
But ensuring that JSPs and Velocity templates can coexist in the same webapp
is important. That's the only way to get people to migrate. It can't be
all or nothing.
> 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 agree in principle, although an example that illustrates this would
better make the point.
>> - 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!
But it has to tie back to the same concepts.
>
>> - 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.
So again, we have two distinct audiences - and we don't want two distinct
toolsets, right?
>
>> - 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.
That is one of the strangest things about the Struts tag set, is the HTML
tags....
It does encapsulate some of the aspects of doing things, so you can fix in
one place when something changes (like HTML->XHTML) However, it's in Java
code, which to me is the wrong place.
We have talked a bit about Velocimacros for this, but never came to a
conclusion.
>
> 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.
Especially because no API like the tag API has to be implemented.
>
>> 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.
If you guys could find some middle ground to stand on, that would be great.
Can we start with one tool and work on that?
>> 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).
>
Lets start with MessageTool...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
