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
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
