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 2002/02/12 20:23:03 UTC
velocity-tools-view/struts contribution
Hey Geir et. al.,
I just went through the process of developing a struts/velocity app, and i
must say the vel-struts codebase is woefully lacking at the moment. In
fact, the velocity-tools-struts package is currently so ugly, i didn't use
any of it in my app. (No offense intended to the authors :-) But, rather
than just complain, i figured i should chip in some of the stuff i ended up
writing.
Attached are four classes that would probably fit best with the view package
(they are not related to Struts) and one that aspires to go in the
vel-struts package (MessageTool). Also included is a velocity template that
demonstrates the use of a couple of the tools. I know some of this
functionality has already been implemented (especially in the case of the
vel-struts class), but seeing as the current codebase is extremely young and
umm...unrefined :-), i think some rigorous competition can only help, right?
Anyway, i found developing with these attached tools to be quite pleasant
and i feel inclined to share.
Nathan Bubna
nathan@esha.com
Re: velocity-tools-view/struts contribution
Posted by Incze Lajos <in...@mail.matav.hu>.
> 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'd avoid copying the struts taglib interface, also. There are functionalities
in jsp that would be hard and superfluous to mimic (e.g. the essentially
nesting character of the jsp tags). On the other hand, taglibs will be purged
out of struts in favor of the standard jsp library. So, building 'native'
velocity-struts view support and documenting the paralellisms (in some howto
manner) can really be a better idea.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 8:10 PM, "Nathan Bubna" <na...@esha.com> 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. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Nathan Bubna <na...@esha.com>.
[...]
> > 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
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna 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.
> the LinkTool class (which is not Struts dependant) also duplicates some
> portions of the StrutsHtmlTool (link(), baseRef(), and whatnot), and again I
> would argue it does a far better job of dealing with links in templates.
Again, right from the Struts code base.
Can you be more specific about how you feel it should be improved?
> overall my impression of the vel-struts package so far is that it is written
> to mimic the functionality of the struts taglibs. frankly, i think that is
> the wrong approach. i think having a
> "make-velocity-in-struts-work-like-jsp-in-struts" mentality limits this
> project to a utility for developers who want to port apps from struts/jsp to
> struts/velocity. seeing as i wanted to build an app from scratch with
> struts and velocity, i found the current vel-struts codebase to be poorly
> organized and unintuitive.
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:
- 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.
- 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.
- A similarly structured view API will allow Velocity users to work with
all the existing tutorials, users guide, examples, etc.
- Finally it will help existing Struts developers to make the move to Velocity
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?
> in the same vein, my MathTool (also not Struts dependent) is IMO more
> flexible and robust and has been used (read tested) quite a bit.
The current math tool is really only there because we needed a simple
tool to test the toolbox mechanism, etc. If you have something better I
am glad to replace that.
> i don't mean to be contentious, but i think the current direction of the
> vel-struts project is wrong. you and the other developers are free to
> disagree, of course, and you can take or leave my code as you wish. I'm
> just trying to help out a bit.
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. 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. Fortunately the toolbox support will allow us to
easily replace one tools by another tool. So nothing is written in stone.
The next planned steps are:
1) To get some basic documentation ready, including user guide and reference
documentation for the tools in general and the Struts support specifically.
(I'm currently working on that)
2) Go over the existing Struts View API again and look in details at all
the available API methods. Decide what of it should be made available in the
Velocity world. We don't plan to support the convenience stuff that
generates HTML, like the form tags.
Gabe
> >
> > That's great. We will pull back the Commons 'rupert' as well and get this
> > going.
>
> cool. sounds like there's more demand (and supply :-) out there for a
> DateTool lately. it's probably time you guys put one in the tools
> sub-project to get people using the same one. i like that last suggestion
> today about making it grab the locale from the request. maybe sometime this
> week i'll clean-up/rewrite my old rupert one to do that and follow the
> pattern of the ones i contributed today.
>
> Nathan Bubna
> nathan@esha.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
Yes.
=:o)
Of course, if a presentation layer had very specific requirements, it
may still need to do something on its own. So, the ContextHelper should
first expose the raw elements, so a helper servlet could use those
directly. But, it should also provide a series of convenience methods
that presentation layers like Velocity and JSTL could call directly.
I'd also like to take a closer look at what X2 is doing, and develop a
ContextHelper that will serve the needs of Velocity templates, XLST,
other DOM-based systems, JSP tags, and even (ugh!) JSP actions and
scriptlets. (Anyone else out there?)
All of these systems need the same things from the controller, they just
have different ways of wrapping the data up once they get it.
The JSP taglib support was a necessary proof of concept, but it's time
to move past that now.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
Gabriel Sidler wrote:
>
> Ted,
> Thanks, that's good input. If I understand you right you
> are basically saying
>
> - Define your optimal view API, not worrying much about the
> existing JSP view API
> - From the view API we'll derive a controller API. Ideally, this
> controller API should be able to satify the needs of all view API.
>
> Am I correctly interpreting your input?
>
> Gabe
>
> Ted Husted wrote:
> >
> > Gabriel Sidler wrote:
> > > The focus has be more on proofing the concept that Velocity
> > > and Struts without major changes on either side.
> >
> > As a Struts committer, I'm of the opinion that the controller should be
> > doing more to make its API accessible to other presentation systems,
> > like Velocity, JSLT, and DOM-based system.
> >
> > The controller's API exposes elements defined in the Struts
> > configuration file and the message resources. In Struts 1.0, a special
> > helper class, RequestUtils, gives JSP tags access to the controller's
> > API. Now that we are past that proof of concept, the next step is to
> > generalized those utilities into an API object that more presentation
> > systems can use.
> >
> > My first pass at the object was the ContextHelper,
> >
> > http://husted.com/struts/resources/ContextHelper.java
> >
> > In Struts 1.1, this can be created by the controller, or perhaps by an
> > optional service. In Struts 1.0, it could be created by a helper
> > servlet.
> >
> > Craig picked up on the idea of a request-based helper, and rolled into a
> > larger plan for supporting multiple configuration files. The changes
> > were sweeping, and now I have to go back and retrofit the ContextHelper
> > (or its successor) for the new controller.
> >
> > If you want to build a Velocity-specific tool, that is of course your
> > perogative, and I will do whatever I can to promote the use of that
> > tool. But originally I hoped that we could collaborate on a way Struts
> > could expose the controller's API to various presentation systems, to
> > minimize, or eliminate, the need to build view-specific helpers.
> >
> > While I appreciate the sentiment of not requiring changes to Struts,
> > it's easy for that to devolve into a bandage that doesn't address the
> > core issue. Which, for me, is how can Struts best expose the
> > controller's API to the presentation layer.
> >
> > Personally, I would suggest avoiding looking at the controller API and
> > the view API as part of the same banana. The controller API should
> > provide data to the view API, and the view API should then package that
> > data for the presention system (e.g. HTML). So, once the view API is
> > defined, we should work backward and ask what data can the controller
> > API provide so the view API can do it's job.
> >
> > The type of data that the controller can provide involves these
> > elements:
> >
> > ActionForwards - provide a logical name for an URI, so it is not
> > embedded in the page.
> >
> > ActionForms - a JavaBean "buffer" for HTML controls, with a hook for
> > automatic validation.
> >
> > ActionMappings - a configuration object for a server-side Action. Most
> > often the target for a HTML form.
> >
> > MessageResouces - provides localised messages and labels.
> >
> > My concern is that if the focus is placed on the superficial aspects of
> > the Struts taglibs, then the deeper issue of what the tags are trying to
> > do will be lost. The forest won't be seen for the trees. The taglibs are
> > the JSP View API, and trying to shoehorn that into another presentation
> > system may not be worthwhile.
> >
> > The missing link is a coherent controller API that can be leveraged by
> > the JSP View and all other view APIs (like "X2", for example). Since
> > many of the controller API elements live in the request, the only place
> > a complete API object can live is in the request.
> >
> > What would be most useful to me, would be if work progresses on the
> > ContextHelper object - or one like it - that could be generated for
> > Struts 1.0 applications, and migrated back a standard part of the Strus
> > 1.1 control flow. Moving forward, there will be an object like this in
> > Struts 1.1. It's just a matter of whether you would like to use it in
> > this package, or roll your own.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Java Web Development with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> Gabriel Sidler
> Software Engineer, Eivycom GmbH, Zurich, Switzerland
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Nathan Bubna <na...@esha.com>.
Ted Husted said:
> Personally, I believe it would be better to provide a "flat" object to
> access the core controller API, which is what I started to do here:
>
> http://husted.com/struts/resources/velservlet.zip
>
> Once you remove the HTML-generation, bean-access, and logic-access
> features of the taglibs, which are not relevant to Velocity, there is
> not so much left. Most of it is encapsulated in this (demo-grade) helper
> class, designed to be created by the controller and inserted into the
> rquest.
Interesting. i think your ContextHelper is alright (fyi, beware the current
errors() method :-)), and i fully agree we should be concentrating on
providing full-access to the controller API rather than making tools with
superficial similarity to the taglibs. But i'm not really a fan of a
one-object-fits-all approach. I would prefer to see different functions
assigned to different tools. While one might argue that everything
ContextHelper does is a 'struts function' and should therefore be combined,
such a categorization is a bit too broad for my tastes. i would rather have
separate tools in my templates to handle URIs, message resources, etc. than
have only one 'struts' or 'get' tool doing everything. Further, i think
with a one-object-for-all-views, we fail to take advantage of the various
features of different views. For example, in the case of Velocity, i find
the ability to do $msg.foo instead of $get.message('foo') to be really
cool. It is cleaner, simpler, and just as easy to understand when looking
at the template src.
All this is to say that I favor Geir's suggestion:
> What I think would be nice is if there was a map of the data elements in
the
> servlet scopes, so anyone could write a tool to access what they needed.
> You also then don't have to have agreement on what this tool is called,
what
> the interfaces look like, etc.
and i think i see your point that the ContextHelper or something like it
(see Geir's concerns about it) could serve as just that. So, if that's what
ends up being done, so be it. Other views can then use the ContextHelper
(or whatever this controller API turns out to be) directly if they wish or
write their own presentation layer to sit on top of it.
As for the Velocity/Struts sub-project, i would like to see it have its own
presentation layer (whether by the latter option above or by directly
accessing said resources) and group like functions into their own classes.
These can then provide a very clean, velocity-friendly view API.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> Will Struts formalize a 'contract' with those resources, or is it "Use our
> tool or you are screwed..."
I don't actually see how we could do that, even if we wanted to -:o)
> Also, what happens if I want to use the struts controller outside of a
> webapp? Will that be possible?
As a practical matter, I'm not sure that it's really possible now. A
non-http action was defined at the beginning, but I'm not sure that
anyone is using it, or how well it would work in practice.
> I agree 100%. I just don't think it necessarily has to be a single API
> object, but more like a definition about where things will be that all users
> can get to.
The definitiosn are laid out in the Action class.
http://jakarta.apache.org/struts/api/org/apache/struts/action/Action.html
via the *_KEY statics.
The RequestUtil class taps these defintions directly, but I think we
agree that a better way to go is to define an actual API object to
encapsulate these definitions.
One approach would be to define an API object for each servlet context,
and have them progressively reveal each other. The Session-scope API
would extend Application-scope API, and the Request-scope API would
extend the Session-scope API.
If another platform used something other than Request-scope, they could
extend the Session-scope API their own way. It's just that there are
framework elements, like messages, that are user or user-locale
specific, and so live in the Request scope. These have to be handled
some way. But, looking at the forest, what we are really talking about
is global-scope objects, user-scope objects, and presentation-scope
elements, which can each be presented on their own "layer" of the
controller's API. The standard HTTP implementation of the
presentation-scope layer would look to the HttpRequest, but another
implementation could look elsewhere.
Sound like plan?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 7:55 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> On 2/13/02 7:35 AM, "Ted Husted" <hu...@apache.org> wrote:
>
>>
>> It's important to remember that I am not concerned only with Velocity,
>> but with all presentation layers, including JSTL, XLST, et cetera. If
>> people want work work on a Velocity-specific solution, that's their
>> perogative. If people want to collaborate on a shared API object, even
>> better.
>
> I agree 100%. I just don't think it necessarily has to be a single API
> object, but more like a definition about where things will be that all users
> can get to. If it can be decoupled from the Servlet API, so much the
> better, I think.
>
I consider my ability to quickly disagree with myself a *strength* :)
I can see that a single object is nice. However, my issues as a hopeful
customer are, just so its clear
o Concern : That the requirements of a broad audience like Vel, JSTL, XSLT
will result in compromises in the API object that a resource contract would
avoid
o Hope : that access to this object/contract can be abstracted away from
the Servlet API so Struts can be used outside of a webapp. Upon reflection,
this level of abstraction may require a single API object :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I was thinking about this in the car - Struts now has a new set of
customers- the seething masses of non-J2EE sanctioned view technologies for
webapps
:)
More inline...
On 2/13/02 7:35 AM, "Ted Husted" <hu...@apache.org> wrote:
> "Geir Magnusson Jr." wrote:
>> 1) Why isn't this stuff on the jakarta struts site, in a sandbox or contrib
>> area?
>
> It was taken out temporarily when the support for modular applications
> was added. I haven't had a chance to put it back in yet. The support for
> modular applications introduced a new base object that I can now extend.
>
>
Cool!
>
>> 2) It sounds to me like you are declaring what you are going to do - your
>> mind is made up.
>
> Yes, I have decided that the Struts controller should provide better
> support for presentation layers, and will be spending my volunteer hours
> working toward that end.
>
> If people want to take advantage of this feature, I'm always happy to
> collaborate.
>
> If people want to go a different way, I'll be happy to provide whatever
> information I can.
I guess my point is along the lines above - you now have a new set of
'customers', ones that are willing to participate in the development.
Also, my issue isn't about what you are spending your volunteer hours doing,
which is great and should be what you want, but more along the lines of not
then making it the only solution to the problem.
Not that I am advocating direct support for every kind of view layer known,
but maybe establishing as flexible an 'access contract' as possible that the
templating wierdo's like us can write to, and not worry that you will change
it on a whim...
>
>
>> Gabriel was pretty successful, and I assume Nathan as well, in beginning
>> from their own starting point and achieving a solution. I am interested in
>> looking at Nathans as he wasn't a struts or JSP guy - he was a Velocity user
>> coming at it from the viewpoint of just needing the functionality of the
>> controller and the resources it exposed.
>
> As I remember, Gabriel's initial work was based on the ContextHelper.
> After spending several long hours in email exchanges like this, I begged
> off and you and Gabriel finished up on your own. At this point, I'm
> presenting the opportunity to merge this initative with the Struts
> development stream. But, if developers choose to pursue other avenues,
> that's their perogative. I'll continue to provide whatever technical
> support I can.
Well, I think Gabriel on his own initiative took the independent approach
before you begged off...
>
>
>
>> I assume neither depended upon the One True Tool presented by the controller
>> to do it since there is none. The fact that they could do it that way is a
>> pretty strong endorsement of what Struts does now, and maybe something could
>> be taken from that as you change it.
>>
>> I am also worried that you are going to close the door to unconventional
>> view layers if you nail down the resource contract in a tool provided by
>> yourself...
>
> All that I am saying is that there is and will be an API object in the
> request that a "tool" can choose to use. There would be nothing to
> prevent a helper servlet from ignoring that object and gaining direct
> access to the same resources, and expose those resources to its tools in
> any way it chooses.
Will Struts formalize a 'contract' with those resources, or is it "Use our
tool or you are screwed..."
That's all I'm worried about.
Also, what happens if I want to use the struts controller outside of a
webapp? Will that be possible?
>
> It's important to remember that I am not concerned only with Velocity,
> but with all presentation layers, including JSTL, XLST, et cetera. If
> people want work work on a Velocity-specific solution, that's their
> perogative. If people want to collaborate on a shared API object, even
> better.
I agree 100%. I just don't think it necessarily has to be a single API
object, but more like a definition about where things will be that all users
can get to. If it can be decoupled from the Servlet API, so much the
better, I think.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Age and treachery will always triumph over youth and talent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> 1) Why isn't this stuff on the jakarta struts site, in a sandbox or contrib
> area?
It was taken out temporarily when the support for modular applications
was added. I haven't had a chance to put it back in yet. The support for
modular applications introduced a new base object that I can now extend.
> 2) It sounds to me like you are declaring what you are going to do - your
> mind is made up.
Yes, I have decided that the Struts controller should provide better
support for presentation layers, and will be spending my volunteer hours
working toward that end.
If people want to take advantage of this feature, I'm always happy to
collaborate.
If people want to go a different way, I'll be happy to provide whatever
information I can.
> Gabriel was pretty successful, and I assume Nathan as well, in beginning
> from their own starting point and achieving a solution. I am interested in
> looking at Nathans as he wasn't a struts or JSP guy - he was a Velocity user
> coming at it from the viewpoint of just needing the functionality of the
> controller and the resources it exposed.
As I remember, Gabriel's initial work was based on the ContextHelper.
After spending several long hours in email exchanges like this, I begged
off and you and Gabriel finished up on your own. At this point, I'm
presenting the opportunity to merge this initative with the Struts
development stream. But, if developers choose to pursue other avenues,
that's their perogative. I'll continue to provide whatever technical
support I can.
> I assume neither depended upon the One True Tool presented by the controller
> to do it since there is none. The fact that they could do it that way is a
> pretty strong endorsement of what Struts does now, and maybe something could
> be taken from that as you change it.
>
> I am also worried that you are going to close the door to unconventional
> view layers if you nail down the resource contract in a tool provided by
> yourself...
All that I am saying is that there is and will be an API object in the
request that a "tool" can choose to use. There would be nothing to
prevent a helper servlet from ignoring that object and gaining direct
access to the same resources, and expose those resources to its tools in
any way it chooses.
It's important to remember that I am not concerned only with Velocity,
but with all presentation layers, including JSTL, XLST, et cetera. If
people want work work on a Velocity-specific solution, that's their
perogative. If people want to collaborate on a shared API object, even
better.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 6:45 AM, "Ted Husted" <hu...@apache.org> wrote:
> I'm just giving the gang a heads-up on what I will be doing, Geir.
Thanks, Ted. I consider myself one of the gang.
>
> There is now and will be a request-scope API object in Struts Nightly
> Build and Struts 1.1. I will be building on that to provide the
> functionality first outlined in the ContextHelper, and demonstrated
> here:
>
> http://husted.com/struts/resources/velservlet.zip
>
> Like the ContextHelper, the Struts 1.1 API object will provide methods
> that presentation layer devices, like Velocity and the JSTL can call
> directly. I may also provide a helper servlet or Action that will make
> this same functionality available to Struts 1.0.x.
>
> I just want to give Gabriel and Nathan the opportunity to leverage what
> Struts will be providing. If they want to contribute to the development
> of this object, even better. If they want to roll their own ... well
> it's their time to volunteer, and I will happily promote anything they
> release, as I have always done with any Struts-related component.
>
> http://husted.com/struts/resources.htm
>
> I'm getting ready to make some changes to the Struts Web site to
> highlight the changes for the upcoming Struts 1.1 release, and will be
> able to include more on the web site about using Velocity with Struts. I
> think Velocity will be very useful to a great number of Struts
> developers, and want do what I can to ensure that the development is
> forward-looking and remains compatible with future releases.
>
I guess I have two questions :
1) Why isn't this stuff on the jakarta struts site, in a sandbox or contrib
area?
2) It sounds to me like you are declaring what you are going to do - your
mind is made up.
Gabriel was pretty successful, and I assume Nathan as well, in beginning
from their own starting point and achieving a solution. I am interested in
looking at Nathans as he wasn't a struts or JSP guy - he was a Velocity user
coming at it from the viewpoint of just needing the functionality of the
controller and the resources it exposed.
I assume neither depended upon the One True Tool presented by the controller
to do it since there is none. The fact that they could do it that way is a
pretty strong endorsement of what Struts does now, and maybe something could
be taken from that as you change it.
I am also worried that you are going to close the door to unconventional
view layers if you nail down the resource contract in a tool provided by
yourself...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
I'm just giving the gang a heads-up on what I will be doing, Geir.
There is now and will be a request-scope API object in Struts Nightly
Build and Struts 1.1. I will be building on that to provide the
functionality first outlined in the ContextHelper, and demonstrated
here:
http://husted.com/struts/resources/velservlet.zip
Like the ContextHelper, the Struts 1.1 API object will provide methods
that presentation layer devices, like Velocity and the JSTL can call
directly. I may also provide a helper servlet or Action that will make
this same functionality available to Struts 1.0.x.
I just want to give Gabriel and Nathan the opportunity to leverage what
Struts will be providing. If they want to contribute to the development
of this object, even better. If they want to roll their own ... well
it's their time to volunteer, and I will happily promote anything they
release, as I have always done with any Struts-related component.
http://husted.com/struts/resources.htm
I'm getting ready to make some changes to the Struts Web site to
highlight the changes for the upcoming Struts 1.1 release, and will be
able to include more on the web site about using Velocity with Struts. I
think Velocity will be very useful to a great number of Struts
developers, and want do what I can to ensure that the development is
forward-looking and remains compatible with future releases.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 6:12 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Ted,
> Thanks, that's good input. If I understand you right you
> are basically saying
>
> - Define your optimal view API, not worrying much about the
> existing JSP view API
How do you do this?
We in Velocity can come up with a view API that is optimal for us. However,
other systems may need a different API?
I saw ted's post about the 'raw' API, but I am not convinced that wouldn't
be tailored to a specific approach. For example, can you make it not
require it having to be passed in a page request scope?
With a clean low-level API, each view system can roll their own.
Maybe the ContextHelper is your low-level API (but I suspect it will be
passed around in a scope...)
> - From the view API we'll derive a controller API. Ideally, this
> controller API should be able to satify the needs of all view API.
I have the same questions as above for this point...
I guess we see what Gabriel proposes today, and what Nathan's response is as
a familiar-with-Velocity new struts user.
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Gabriel Sidler <si...@teamup.ch>.
Ted,
Thanks, that's good input. If I understand you right you
are basically saying
- Define your optimal view API, not worrying much about the
existing JSP view API
- From the view API we'll derive a controller API. Ideally, this
controller API should be able to satify the needs of all view API.
Am I correctly interpreting your input?
Gabe
Ted Husted wrote:
>
> Gabriel Sidler wrote:
> > The focus has be more on proofing the concept that Velocity
> > and Struts without major changes on either side.
>
> As a Struts committer, I'm of the opinion that the controller should be
> doing more to make its API accessible to other presentation systems,
> like Velocity, JSLT, and DOM-based system.
>
> The controller's API exposes elements defined in the Struts
> configuration file and the message resources. In Struts 1.0, a special
> helper class, RequestUtils, gives JSP tags access to the controller's
> API. Now that we are past that proof of concept, the next step is to
> generalized those utilities into an API object that more presentation
> systems can use.
>
> My first pass at the object was the ContextHelper,
>
> http://husted.com/struts/resources/ContextHelper.java
>
> In Struts 1.1, this can be created by the controller, or perhaps by an
> optional service. In Struts 1.0, it could be created by a helper
> servlet.
>
> Craig picked up on the idea of a request-based helper, and rolled into a
> larger plan for supporting multiple configuration files. The changes
> were sweeping, and now I have to go back and retrofit the ContextHelper
> (or its successor) for the new controller.
>
> If you want to build a Velocity-specific tool, that is of course your
> perogative, and I will do whatever I can to promote the use of that
> tool. But originally I hoped that we could collaborate on a way Struts
> could expose the controller's API to various presentation systems, to
> minimize, or eliminate, the need to build view-specific helpers.
>
> While I appreciate the sentiment of not requiring changes to Struts,
> it's easy for that to devolve into a bandage that doesn't address the
> core issue. Which, for me, is how can Struts best expose the
> controller's API to the presentation layer.
>
> Personally, I would suggest avoiding looking at the controller API and
> the view API as part of the same banana. The controller API should
> provide data to the view API, and the view API should then package that
> data for the presention system (e.g. HTML). So, once the view API is
> defined, we should work backward and ask what data can the controller
> API provide so the view API can do it's job.
>
> The type of data that the controller can provide involves these
> elements:
>
> ActionForwards - provide a logical name for an URI, so it is not
> embedded in the page.
>
> ActionForms - a JavaBean "buffer" for HTML controls, with a hook for
> automatic validation.
>
> ActionMappings - a configuration object for a server-side Action. Most
> often the target for a HTML form.
>
> MessageResouces - provides localised messages and labels.
>
> My concern is that if the focus is placed on the superficial aspects of
> the Struts taglibs, then the deeper issue of what the tags are trying to
> do will be lost. The forest won't be seen for the trees. The taglibs are
> the JSP View API, and trying to shoehorn that into another presentation
> system may not be worthwhile.
>
> The missing link is a coherent controller API that can be leveraged by
> the JSP View and all other view APIs (like "X2", for example). Since
> many of the controller API elements live in the request, the only place
> a complete API object can live is in the request.
>
> What would be most useful to me, would be if work progresses on the
> ContextHelper object - or one like it - that could be generated for
> Struts 1.0 applications, and migrated back a standard part of the Strus
> 1.1 control flow. Moving forward, there will be an object like this in
> Struts 1.1. It's just a matter of whether you would like to use it in
> this package, or roll your own.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Java Web Development with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
Gabriel Sidler wrote:
> The focus has be more on proofing the concept that Velocity
> and Struts without major changes on either side.
As a Struts committer, I'm of the opinion that the controller should be
doing more to make its API accessible to other presentation systems,
like Velocity, JSLT, and DOM-based system.
The controller's API exposes elements defined in the Struts
configuration file and the message resources. In Struts 1.0, a special
helper class, RequestUtils, gives JSP tags access to the controller's
API. Now that we are past that proof of concept, the next step is to
generalized those utilities into an API object that more presentation
systems can use.
My first pass at the object was the ContextHelper,
http://husted.com/struts/resources/ContextHelper.java
In Struts 1.1, this can be created by the controller, or perhaps by an
optional service. In Struts 1.0, it could be created by a helper
servlet.
Craig picked up on the idea of a request-based helper, and rolled into a
larger plan for supporting multiple configuration files. The changes
were sweeping, and now I have to go back and retrofit the ContextHelper
(or its successor) for the new controller.
If you want to build a Velocity-specific tool, that is of course your
perogative, and I will do whatever I can to promote the use of that
tool. But originally I hoped that we could collaborate on a way Struts
could expose the controller's API to various presentation systems, to
minimize, or eliminate, the need to build view-specific helpers.
While I appreciate the sentiment of not requiring changes to Struts,
it's easy for that to devolve into a bandage that doesn't address the
core issue. Which, for me, is how can Struts best expose the
controller's API to the presentation layer.
Personally, I would suggest avoiding looking at the controller API and
the view API as part of the same banana. The controller API should
provide data to the view API, and the view API should then package that
data for the presention system (e.g. HTML). So, once the view API is
defined, we should work backward and ask what data can the controller
API provide so the view API can do it's job.
The type of data that the controller can provide involves these
elements:
ActionForwards - provide a logical name for an URI, so it is not
embedded in the page.
ActionForms - a JavaBean "buffer" for HTML controls, with a hook for
automatic validation.
ActionMappings - a configuration object for a server-side Action. Most
often the target for a HTML form.
MessageResouces - provides localised messages and labels.
My concern is that if the focus is placed on the superficial aspects of
the Struts taglibs, then the deeper issue of what the tags are trying to
do will be lost. The forest won't be seen for the trees. The taglibs are
the JSP View API, and trying to shoehorn that into another presentation
system may not be worthwhile.
The missing link is a coherent controller API that can be leveraged by
the JSP View and all other view APIs (like "X2", for example). Since
many of the controller API elements live in the request, the only place
a complete API object can live is in the request.
What would be most useful to me, would be if work progresses on the
ContextHelper object - or one like it - that could be generated for
Struts 1.0 applications, and migrated back a standard part of the Strus
1.1 control flow. Moving forward, there will be an object like this in
Struts 1.1. It's just a matter of whether you would like to use it in
this package, or roll your own.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 2:20 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> I propose the following to move on:
> As I mentioned earlier, I have been planning a review of the view API
> after I get done with some basic documentation. Due to the discussion
> I will now change my plans and create an overview and proposal for the
> view API today. Now that a few people have tried out the tools we can
> have a discussion on this. I had a look at the message tool by
> Nathan. I don't think it is so fundamentally that we woundn't find a common
> ground. So far we havn't really thought much about the design of the
> view API. The focus has be more on proofing the concept that Velocity
> and Struts without major changes on either side.
+1
>
> Look for a mail later today.
>
> Gabe
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Gabriel Sidler <si...@teamup.ch>.
I propose the following to move on:
As I mentioned earlier, I have been planning a review of the view API
after I get done with some basic documentation. Due to the discussion
I will now change my plans and create an overview and proposal for the
view API today. Now that a few people have tried out the tools we can
have a discussion on this. I had a look at the message tool by
Nathan. I don't think it is so fundamentally that we woundn't find a common
ground. So far we havn't really thought much about the design of the
view API. The focus has be more on proofing the concept that Velocity
and Struts without major changes on either side.
Look for a mail later today.
Gabe
"Geir Magnusson Jr." wrote:
>
> On 2/12/02 10:49 PM, "Ted Husted" <hu...@apache.org> wrote:
>
> > "Geir Magnusson Jr." wrote:
> >> Inserting into the request is problematic, as this makes some assumptions.
> >
> > The new support for modular applications relies on a request-scope
> > object, so this will be the cannonical Struts approach.
>
> What happens if someone wants to use the struts controller outside of the
> servlet API?
>
> >
> >
> >> What I think would be nice is if there was a map of the data elements in the
> >> servlet scopes, so anyone could write a tool to access what they needed.
> >> You also then don't have to have agreement on what this tool is called, what
> >> the interfaces look like, etc.
> >
> > That's part of what the ContextHelper can do. Someone could just tap
> > into the accessors for the data elements, to get what they needed for
> > their own presentation layer.
>
> Ah - so nothing *except* the ContextHelper will be in the scopes?
>
> > The end-game would be to turn around and have the tag exensions use this
> > object too. So, it's going to be there whether someone chooses to use it
> > or not.
>
> Yep. Although maybe you could start the game that way :)
>
> >
> >> In Velocity, since we don't have any trouble accessing things that aren't
> >> simple property getter/setter methods, we can access a really rich API, and
> >> therefore would be pleased to avoid a lowest-common-denominator object
> >> provided by the controller.
> >
> > I actually like to think of it as a highest-common-denominator object
> > =:o)
>
> As long as the API isn't shaped by the necessity of being dumbed-down to a
> bean for easy tag access, indeed...
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> The bytecodes are language independent. - Sam Ruby
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 10:49 PM, "Ted Husted" <hu...@apache.org> wrote:
> "Geir Magnusson Jr." wrote:
>> Inserting into the request is problematic, as this makes some assumptions.
>
> The new support for modular applications relies on a request-scope
> object, so this will be the cannonical Struts approach.
What happens if someone wants to use the struts controller outside of the
servlet API?
>
>
>> What I think would be nice is if there was a map of the data elements in the
>> servlet scopes, so anyone could write a tool to access what they needed.
>> You also then don't have to have agreement on what this tool is called, what
>> the interfaces look like, etc.
>
> That's part of what the ContextHelper can do. Someone could just tap
> into the accessors for the data elements, to get what they needed for
> their own presentation layer.
Ah - so nothing *except* the ContextHelper will be in the scopes?
> The end-game would be to turn around and have the tag exensions use this
> object too. So, it's going to be there whether someone chooses to use it
> or not.
Yep. Although maybe you could start the game that way :)
>
>> In Velocity, since we don't have any trouble accessing things that aren't
>> simple property getter/setter methods, we can access a really rich API, and
>> therefore would be pleased to avoid a lowest-common-denominator object
>> provided by the controller.
>
> I actually like to think of it as a highest-common-denominator object
> =:o)
As long as the API isn't shaped by the necessity of being dumbed-down to a
bean for easy tag access, indeed...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
"Geir Magnusson Jr." wrote:
> Inserting into the request is problematic, as this makes some assumptions.
The new support for modular applications relies on a request-scope
object, so this will be the cannonical Struts approach.
> What I think would be nice is if there was a map of the data elements in the
> servlet scopes, so anyone could write a tool to access what they needed.
> You also then don't have to have agreement on what this tool is called, what
> the interfaces look like, etc.
That's part of what the ContextHelper can do. Someone could just tap
into the accessors for the data elements, to get what they needed for
their own presentation layer.
The end-game would be to turn around and have the tag exensions use this
object too. So, it's going to be there whether someone chooses to use it
or not.
> In Velocity, since we don't have any trouble accessing things that aren't
> simple property getter/setter methods, we can access a really rich API, and
> therefore would be pleased to avoid a lowest-common-denominator object
> provided by the controller.
I actually like to think of it as a highest-common-denominator object
=:o)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 10:05 PM, "Ted Husted" <hu...@apache.org> wrote:
> Nathan Bubna wrote:
>> overall my impression of the vel-struts package so far is that it is written
>> to mimic the functionality of the struts taglibs. frankly, i think that is
>> the wrong approach.
>
> I agree.
>
> The focus should be on the controller's API, which flows from the
> elements defined in the Struts configuration.
>
> ActionForward - provides a logical name for an URI, so it is not
> embedded in the page.
>
> ActionForms - a JavaBean "buffer" for HTML controls, with a hook for
> automatic validation.
>
> ActionMappings - a configuration object for a server-side Action. Most
> often the target for a HTML form.
>
> MessageResouces - provides localised messages and labels.
>
> The Struts taglibs are one way to access this API ... among other
> things. The vast majority of the Struts tags are not even relevant to
> the controller's API, but strive to provide generic functionality
> already built into Velocity.
>
> Personally, I believe it would be better to provide a "flat" object to
> access the core controller API, which is what I started to do here:
>
> http://husted.com/struts/resources/velservlet.zip
>
> Once you remove the HTML-generation, bean-access, and logic-access
> features of the taglibs, which are not relevant to Velocity, there is
> not so much left. Most of it is encapsulated in this (demo-grade) helper
> class, designed to be created by the controller and inserted into the
> rquest.
Inserting into the request is problematic, as this makes some assumptions.
What I think would be nice is if there was a map of the data elements in the
servlet scopes, so anyone could write a tool to access what they needed.
You also then don't have to have agreement on what this tool is called, what
the interfaces look like, etc.
In Velocity, since we don't have any trouble accessing things that aren't
simple property getter/setter methods, we can access a really rich API, and
therefore would be pleased to avoid a lowest-common-denominator object
provided by the controller.
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Ted Husted <hu...@apache.org>.
Nathan Bubna wrote:
> overall my impression of the vel-struts package so far is that it is written
> to mimic the functionality of the struts taglibs. frankly, i think that is
> the wrong approach.
I agree.
The focus should be on the controller's API, which flows from the
elements defined in the Struts configuration.
ActionForward - provides a logical name for an URI, so it is not
embedded in the page.
ActionForms - a JavaBean "buffer" for HTML controls, with a hook for
automatic validation.
ActionMappings - a configuration object for a server-side Action. Most
often the target for a HTML form.
MessageResouces - provides localised messages and labels.
The Struts taglibs are one way to access this API ... among other
things. The vast majority of the Struts tags are not even relevant to
the controller's API, but strive to provide generic functionality
already built into Velocity.
Personally, I believe it would be better to provide a "flat" object to
access the core controller API, which is what I started to do here:
http://husted.com/struts/resources/velservlet.zip
Once you remove the HTML-generation, bean-access, and logic-access
features of the taglibs, which are not relevant to Velocity, there is
not so much left. Most of it is encapsulated in this (demo-grade) helper
class, designed to be created by the controller and inserted into the
rquest.
http://husted.com/struts/resources/ContextHelper.java
Once the dust clears on the recent changes to the Struts controller, I
think we will get back to providing a controller API object like this in
the request that any reasonable presentation device, like Velocity or
JSTL, can access without modification.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by Nathan Bubna <na...@esha.com>.
[snip]
> > I know some of this
> > functionality has already been implemented (especially in the case of
the
> > vel-struts class), but seeing as the current codebase is extremely young
and
> > umm...unrefined :-), i think some rigorous competition can only help,
right?
>
> Sure - can any of it be combined? Competition is good, but we also want
to
> limit the confusion to users - avoid major overlap (minor isn't so bad...)
hmm. well, 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. take
a look at MessageTool. it's designed to make much better use of velocity's
abilities, and i think it is a better approach.
the LinkTool class (which is not Struts dependant) also duplicates some
portions of the StrutsHtmlTool (link(), baseRef(), and whatnot), and again I
would argue it does a far better job of dealing with links in templates.
in the same vein, my MathTool (also not Struts dependent) is IMO more
flexible and robust and has been used (read tested) quite a bit.
lastly, the PullTool/SearchTool code currently has no peer in the
velocity-tools heirarchy. so, while i readily admit they are less useful to
people, i'm probably not the only one who needs such functionality.
parameter parsing and search results pagination are pretty common needs.
overall my impression of the vel-struts package so far is that it is written
to mimic the functionality of the struts taglibs. frankly, i think that is
the wrong approach. i think having a
"make-velocity-in-struts-work-like-jsp-in-struts" mentality limits this
project to a utility for developers who want to port apps from struts/jsp to
struts/velocity. seeing as i wanted to build an app from scratch with
struts and velocity, i found the current vel-struts codebase to be poorly
organized and unintuitive.
i don't mean to be contentious, but i think the current direction of the
vel-struts project is wrong. you and the other developers are free to
disagree, of course, and you can take or leave my code as you wish. I'm
just trying to help out a bit.
> > Anyway, i found developing with these attached tools to be quite
pleasant
> > and i feel inclined to share.
>
> That's great. We will pull back the Commons 'rupert' as well and get this
> going.
cool. sounds like there's more demand (and supply :-) out there for a
DateTool lately. it's probably time you guys put one in the tools
sub-project to get people using the same one. i like that last suggestion
today about making it grab the locale from the request. maybe sometime this
week i'll clean-up/rewrite my old rupert one to do that and follow the
pattern of the ones i contributed today.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: velocity-tools-view/struts contribution
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 2:23 PM, "Nathan Bubna" <na...@esha.com> wrote:
> Hey Geir et. al.,
>
> I just went through the process of developing a struts/velocity app, and i
> must say the vel-struts codebase is woefully lacking at the moment. In
> fact, the velocity-tools-struts package is currently so ugly, i didn't use
> any of it in my app. (No offense intended to the authors :-) But, rather
> than just complain, i figured i should chip in some of the stuff i ended up
> writing.
Hm.
>
> Attached are four classes that would probably fit best with the view package
> (they are not related to Struts) and one that aspires to go in the
> vel-struts package (MessageTool). Also included is a velocity template that
> demonstrates the use of a couple of the tools. I know some of this
> functionality has already been implemented (especially in the case of the
> vel-struts class), but seeing as the current codebase is extremely young and
> umm...unrefined :-), i think some rigorous competition can only help, right?
Sure - can any of it be combined? Competition is good, but we also want to
limit the confusion to users - avoid major overlap (minor isn't so bad...)
> Anyway, i found developing with these attached tools to be quite pleasant
> and i feel inclined to share.
That's great. We will pull back the Commons 'rupert' as well and get this
going.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>