You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Gabriel Sidler <si...@teamup.ch> on 2002/03/05 12:12:45 UTC
Re: [VelTools] Velocity for Struts
Hi,
based on the discussed API for Velocity for Struts I implemented
the context tools. I have put together a demo application that
incudes several small application examples as well as reference
documentation for the context tools. The demo can be downloaded
from
http://www.teamup.com/velstruts/velstruts.war [1.3 MB]
This is a ready-to-deploy war file. Put it into the webapps
directory of your favorite servlet container and restart. Then
point your browser at http://yourserver:port/velstruts/
While implementing the API I came across several weaknesses of
the discussed API. I made the changes outlined below. Please review
and yell if you feel something is going the wrong way. Please refer
to the reference documentation in the war files for details.
The code is now structured such that all Struts Know-How is
kept in a class StrutsUtils. This is a utility class with all
static methods. All context tools use it to access to the
Struts resources. This avoids the spreading of Struts Know How
all over. The methods of StrutsUtils reflect what Velocity context
tools need from Struts. I hope that at some point these
utilities can be integrated into Struts itself.
I introduced an abstract context tool ServletContextTool. All
Struts context tools extend ServletContextTool. It provides
logging to the logging facility provided by the Servlet API.
I am not fully satisfied yet with this approach. I think we
should forsee logging support already in the ContextTool interface.
My intention is now to wait for feedback, make necessary
improvements and then commit this software to
jakarta-velocity-tools within about a week.
My next planned steps are the following:
- setup test cases
- add documentation: overview, user guide, quick reference guide
- make documentation printable
- put together a binary distribution with examples and a blank
application and announce it to the world
- add ActionMessagesTool
- rework the current logging concept for context tools
- add capability to config Velocity
- remove Velocity's [INFO] logging for each template
Your feedback is appreciated.
Gabe
--------------------------------------------------------------------
API Changes in 0.6:
- MessageTool
- Added method public get(String key, ArrayList args). It's more
Velocity compatible than get(String key, Object[]). I left
the latter to stay compatibility with existing apps.
- LinkTool:
- Renamed setPath() to setURI(). This method takes absolute
URIs, server-relative URIs, relative URIs and URIs with query
parameters. The new name is more accurately reflecting what the
method does.
- Renamed getServerPath() to getContextURI(). This naming is
consistent with the naming used in the Servlet API and it seems
also more intuitive.
- Added method getContextPath(). This is a natural complement to
method getContextURI()
- I based my implementation of LinkTool on the implementation
contributed by Nathan. I changed the following aspects:
- Added support to work with relative URIs (in addition to
absolute URIs)
- Added support to work with URIs that point to other servers
- Added support to resolve Struts action names to URI references
- Added support to resolve Struts forwards to URI references
- ErrorsTool:
- Added method public boolean exist(String property). This is a
natural complement to public boolean exist().
- Changed methods get() and getAll() to return ArrayLists instead
of HashMaps. With ArrayList the sequence of error messages is
maintained. This was not the case before.
- Introduced methods getMsgs() and getMsgs(String property). These
two methods generate the necessary markup to display error messages
in the view. All the markup is configurable in the message resources.
We discussed previouly to skip these methods and instead recommend
the use of a macro to render error messages.
While creating some examples for the documentation I realized that
it is very painful to have to write a macro each time you
want to render some error messages. Displaying error messages is
such a basic and frequently needed feature that I feel we need to
provide basic support for it in the ErrorsTool. It is still
possible to use macros to custom format error messages.
- FormTool:
- Added method getTokenName() to retrieve the request parameter name
that must be used for the transaction token. This is necessary to
be able to handle the transaction token.
- ActionMessages:
- Not implmented yet. This is a feature of the upcoming Struts 1.1
release. I need to study this in more detail to really understand
what the intended behavior is in relation to the ErrorMessages
--------------------------------------------------------------------
--
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: [VelTools] Velocity for Struts
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler wrote:
[snip]
> No, no, not at all :-) I am not talking about big clumps of error
> messages. I also prefer to have error messages right next to the input
> element where the error occurs. The current API prototype supports this
> more elegantly than what you propose above IMHO. The property parameter
> of methods get(String property) and exist(String property) have been
> forseen exactly for the purpose of selecting categories of error messages.
> Your above example would be written as follows:
>
> #errorMsgs("username")
> <input type=text name=username value=$form.bean.username><br>
> #errorMsgs("password")
> <input type=text name=password value=$form.bean.password><br>
[snip]
> This has several advantages:
> - it is able to deal with multiple errors
> - error messages don't need to belong to a known set (one app I am
> currently helping with needs to display error messages from a
> CORBA back-end, all possible error messages are not known. Error
> messages may change as remote services change.)
> - error messages are styled appropriately
> - it is no less efficient than your approach if no errors are present
>
> So, I propose that we rely on the approach forseen be Struts to
> achive exactly what you want. This way we don't need to access
> error message by name and we can save the trouble to build our
> own magic sorted map. Using a macro like above is the more solid
> appraoch for view designers.
<img src="light_bulb_turning_on.gif"> Ah! now i get it :-) you'll have to
forgive me and my remaining ignorance of struts. i was using the property
setting to identify errors at the form/page level, rather than at the field
level. now your method makes sense to me. and if that's standard practice,
then returning a List will be fine. i'll just need to change my own
approach.
> ...
> >
> > it's not the fact that HTML was being hardcoded that was the issue, but
> > rather that "design" or "view" decisions were being hardcoded. the
proposed
> > approach takes large steps away from most of that, but not all of it.
what
> > you propose may feel intuitive to you since you are used to the jsp
taglibs,
> > but coming from a velocity user's perspective, it feels very wrong to
me.
> > this sort of thing is exactly the reason we have Velocimacros, i will
> > *never* (seriously, i mean never) be convinced that this belongs in a
tool
> > unless you show me that this cannot be reasonably done with
Velocimacros.
>
> Yeah, I slowly start to think that you might be right on this. So, let's
> do this: I'll look into how to get Velocity config working with
> VelocityViewServlet. Once this works we remove the getMsgs() methods and
> instead provide examples of macros to render the error messages.
sounds good to me.
[snip]
> Thanks for your feedback. It's good to have someone to discuss this with.
> It forces me to think through all these questions hard. The API draft has
> benefited a lot from this.
cool. glad to be of help! i know at the least this discussion is helping
me get a better handle on the struts framework. i think the velocity/struts
combo has some good potential. hopefully as this project develops more
people will get involved to push it along even further.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity for Struts
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
...
>>I never understood this use case:
>>
>>$!errors.login_errors.invalid_username
>>
>>This assumes that you know in advance all possible error messages. In
>>my view this introduces a problematic dependency between the back-end
>>that produces the errors and the front-end that should display the errors.
>>What happens if error messages are renamed, added, removed?
>>
>
> huh? i don't see the problem. according to that argument, the same
> "problem" exists for things like "$msg.welcome". what happens if the
> "welcome" message is renamed or removed? it seems to me that the view
> designer will have to know something about "special names" whether they're
> message resource keys, error message keys, or even input field names. i
> hardly think it is bad practice to assume the designers are familiar with
> the contents of the application resources. in fact, in most cases, i would
> expect them to be writing the messages in those files.
Well, the static output strings defined in the message resource are not
quite comparable to the error messages. The output strings are typically
fully under the control of the web designer. The backend-developer doesn't
need to care about them at all. With error messages it's quite the opposite.
They are defined by the backend-developer to be output by the web designers.
Decoupling their jobs is an important goal. Your approach couples them more
than necessary.
> [snip]
>
>>Can you elaborate on your use case?
>>
> oh, something sorta like this...
>
> $!errors.fooform.field1_invalid
> <input type=text name=field1 value=$form.bean.field1><br>
> $!errors.fooform.field1_notOk
> <input type=text name=field2 value=$form.bean.field2><br>
>
> The basic goal of the usage i describe is to allow error messages to be
> independently displayed in various places throughout the template. the
> method you suggest limits designers to displaying all error messages for a
> request in one big clump on the page.
No, no, not at all :-) I am not talking about big clumps of error
messages. I also prefer to have error messages right next to the input
element where the error occurs. The current API prototype supports this
more elegantly than what you propose above IMHO. The property parameter
of methods get(String property) and exist(String property) have been
forseen exactly for the purpose of selecting categories of error messages.
Your above example would be written as follows:
#errorMsgs("username")
<input type=text name=username value=$form.bean.username><br>
#errorMsgs("password")
<input type=text name=password value=$form.bean.password><br>
where #errorMsgs() is a macro. (#errorMsgs could of course be
a tool method as well, but that's the next topic :-))
The macro would do something like:
#macro ($errorMsgs $property)
#if (errors.exist($property))
$msg.error_notification
<ul>
#foreach ($e in $errors.get($property))
<li>$e</li>
#end
#end
#end
This has several advantages:
- it is able to deal with multiple errors
- error messages don't need to belong to a known set (one app I am
currently helping with needs to display error messages from a
CORBA back-end, all possible error messages are not known. Error
messages may change as remote services change.)
- error messages are styled appropriately
- it is no less efficient than your approach if no errors are present
So, I propose that we rely on the approach forseen be Struts to
achive exactly what you want. This way we don't need to access
error message by name and we can save the trouble to build our
own magic sorted map. Using a macro like above is the more solid
appraoch for view designers.
...
>
> it's not the fact that HTML was being hardcoded that was the issue, but
> rather that "design" or "view" decisions were being hardcoded. the proposed
> approach takes large steps away from most of that, but not all of it. what
> you propose may feel intuitive to you since you are used to the jsp taglibs,
> but coming from a velocity user's perspective, it feels very wrong to me.
> this sort of thing is exactly the reason we have Velocimacros, i will
> *never* (seriously, i mean never) be convinced that this belongs in a tool
> unless you show me that this cannot be reasonably done with Velocimacros.
Yeah, I slowly start to think that you might be right on this. So, let's
do this: I'll look into how to get Velocity config working with
VelocityViewServlet. Once this works we remove the getMsgs() methods and
instead provide examples of macros to render the error messages.
> [snip]
>
>>I am open to anything but really like to be convinced :-)
>>
>
> so..... how am i doing? :-)
Mixed :-)
Thanks for your feedback. It's good to have someone to discuss this with.
It forces me to think through all these questions hard. The API draft has
benefited a lot from this.
Gabe
> 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: [VelTools] Velocity for Struts
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler said:
>
> I am aiming at making Velocity a drop in replacement for JSP and vice
versa.
> If one view technolgy requires ArrayList and the other one requires an
array
> then we have a mismatch that affects not only the view but also the model.
> While an ArrayList can easily be converted to array, the other direction
is
> less straighforward (for a view designer). Therefore two methods.
good enough for me. +1
[snip]
> I never understood this use case:
>
> $!errors.login_errors.invalid_username
>
> This assumes that you know in advance all possible error messages. In
> my view this introduces a problematic dependency between the back-end
> that produces the errors and the front-end that should display the errors.
> What happens if error messages are renamed, added, removed?
huh? i don't see the problem. according to that argument, the same
"problem" exists for things like "$msg.welcome". what happens if the
"welcome" message is renamed or removed? it seems to me that the view
designer will have to know something about "special names" whether they're
message resource keys, error message keys, or even input field names. i
hardly think it is bad practice to assume the designers are familiar with
the contents of the application resources. in fact, in most cases, i would
expect them to be writing the messages in those files.
[snip]
> Can you elaborate on your use case?
oh, something sorta like this...
$!errors.fooform.field1_invalid
<input type=text name=field1 value=$form.bean.field1><br>
$!errors.fooform.field1_notOk
<input type=text name=field2 value=$form.bean.field2><br>
The basic goal of the usage i describe is to allow error messages to be
independently displayed in various places throughout the template. the
method you suggest limits designers to displaying all error messages for a
request in one big clump on the page. frankly, i think that's an undue
restriction. sure, there may be situations where the designer may not know
*all* possible error messages, and may prefer to display them as a list to
avoid missing any, but the designers should be familiar with the message
resources and will often know all the possible messages associated with a
particular form or page. in such cases, it often looks much nicer to
display the messages individually next to their respective input fields or
whatnot. the clump display method may be sufficient for you, but this is a
usage i strongly desire and feel that others will find useful as well. This
should not be a difficult feature to add, and should have no effect on the
performance of your preferred usage. so why not?
[snip]
> What I don't understand it this: Displaying error messages is a very
common
> need. Every typical template will needs this once or serveral times. Why
> should such a common functionality be delegated to a macro instead of to a
tool
> method? Why use tools here and macros there. In my view this makes the
API
> more complex than necessary.
I think you're asking the wrong question. The question is, why put
something into hardcoded java that can be more easily done in a velocimacro?
Your method may no longer be hardcoding HTML, but you are still hardcoding
message resource keys, line breaks, and a pattern of error listing. (i.e.
header then message then footer and so on). Yes, that may be a fairly
standard pattern, and it may provide some minor (though trivial if you ask
me) increase in convenience, but it still means "view" decisions are being
(unnecessarily) hardcoded into java. Why do that when macros can offer the
same functionality with the added benefit of easy customization? coming from
a velocity and not a jsp background, i cringe every time i run into
something like this. just as in the case of returning error messages that
can only be accessed as a list, the "design" decisions i see being made in
the java are subtle, but i think we ought to avoid them wherever possible.
i also don't understand the relevance of this being a common need. of
course, it's a common need, but how does that justify hardcoding this
function in java? i already explained how once we are able to set velocity
props, such a macro will only need to be written once as a global macro. i
think we need to be very careful that we don't get carried away with the
tools here. context tools should be used only as an aid to developing pages
with VTL, not as a replacement.
> In the past one concern was that HTML is generated inside a tool, which is
> not very flexible. I fully agree. But, in this case all HTML is defined in
> the message resources and therefore fully configurable by the template
designer.
> I just don't see any fault with the proposed approach. Similar things
> should work similarly. That's intuitive.
it's not the fact that HTML was being hardcoded that was the issue, but
rather that "design" or "view" decisions were being hardcoded. the proposed
approach takes large steps away from most of that, but not all of it. what
you propose may feel intuitive to you since you are used to the jsp taglibs,
but coming from a velocity user's perspective, it feels very wrong to me.
this sort of thing is exactly the reason we have Velocimacros, i will
*never* (seriously, i mean never) be convinced that this belongs in a tool
unless you show me that this cannot be reasonably done with Velocimacros.
[snip]
> I am open to anything but really like to be convinced :-)
so..... how am i doing? have i convinced you? :-)
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity for Struts
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
...
> > API Changes in 0.6:
> >
> > - MessageTool
> > - Added method public get(String key, ArrayList args). It's more
> > Velocity compatible than get(String key, Object[]). I left
> > the latter to stay compatibility with existing apps.
>
> +1 actually, since this is a tool specifically for use in Velocity
> templates and we're changing most things anyway, i think perhaps we should
> remove the get(String,Object[]) method altogether. i know i'm certainly not
> dependant on it.
I am aiming at making Velocity a drop in replacement for JSP and vice versa.
If one view technolgy requires ArrayList and the other one requires an array
then we have a mismatch that affects not only the view but also the model.
While an ArrayList can easily be converted to array, the other direction is
less straighforward (for a view designer). Therefore two methods.
> > - ErrorsTool:
> > - Added method public boolean exist(String property). This is a
> > natural complement to public boolean exist().
> > - Changed methods get() and getAll() to return ArrayLists instead
> > of HashMaps. With ArrayList the sequence of error messages is
> > maintained. This was not the case before.
>
> ick. that kills the option of doing things like
>
> $!errors.login_errors.invalid_username
>
> and basically forces people to loop over errors like
>
> #foreach( $error in $errors.login_errors)
> $error
> #end
>
> or do something truly evil like
>
> $errors.login_errors.get(0)
>
> instead of allowing them to access individual messages directly by their
> key. so, i find myself conflicted. i agree, we need to have the errors
> maintain their order, but i'm loathe to give up direct access by key.
> perhaps we need to consider returning a Map or List class of our own that
> would maintain the order and still allow get(key) access.
I never understood this use case:
$!errors.login_errors.invalid_username
This assumes that you know in advance all possible error messages. In
my view this introduces a problematic dependency between the back-end
that produces the errors and the front-end that should display the errors.
What happens if error messages are renamed, added, removed?
My understanding is that the best practice approach to displaying
error message is something like:
#if ($errors.exist($property))
$msg.error_notification
<ul>
#foreach ($er in $errors.get($property) )
<li>$er</li>
#end
</ul>
#end
This would of course be wrapped inside a method or macro.
Can you elaborate on your use case?
> > - Introduced methods getMsgs() and getMsgs(String property). These
> > two methods generate the necessary markup to display error messages
> > in the view. All the markup is configurable in the message
> resources.
> > We discussed previouly to skip these methods and instead recommend
> > the use of a macro to render error messages.
> > While creating some examples for the documentation I realized that
> > it is very painful to have to write a macro each time you
> > want to render some error messages. Displaying error messages is
> > such a basic and frequently needed feature that I feel we need to
> > provide basic support for it in the ErrorsTool. It is still
> > possible to use macros to custom format error messages.
>
> -1
>
> ok, i fully agree that it is ridiculous to write an #errorMarkup macro for
> each template, but this is why we need to allow for Velocity configuration.
> the #errorMarkup velocimacro should be a global macro so that you need only
> write it once. still, even as things presently are, you can write it in a
> template on it's own and #parse that template at the top of any other
> templates you need it in.
What I don't understand it this: Displaying error messages is a very common
need. Every typical template will needs this once or serveral times. Why
should such a common functionality be delegated to a macro instead of to a tool
method? Why use tools here and macros there. In my view this makes the API
more complex than necessary.
In the past one concern was that HTML is generated inside a tool, which is
not very flexible. I fully agree. But, in this case all HTML is defined in
the message resources and therefore fully configurable by the template designer.
I just don't see any fault with the proposed approach. Similar things
should work similarly. That's intuitive.
If you need your own customized error messages then macros are a great way
to go.
I am open to anything but really like to be convinced :-)
Gabe
--
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: [VelTools] Velocity for Struts
Posted by Nathan Bubna <na...@esha.com>.
[...]
> I introduced an abstract context tool ServletContextTool. All
> Struts context tools extend ServletContextTool. It provides
> logging to the logging facility provided by the Servlet API.
> I am not fully satisfied yet with this approach. I think we
> should forsee logging support already in the ContextTool interface.
yeah, i'm not fully satisfied with this either. i would prefer at some
point to pass logging off to a more configurable log system. i don't know
anything about what support struts has (if any) for logging, but we should
prefer to hook into that if/when it exists. i would like to see similar
things happen with the logging for the VelocityViewServlet. at present it
is using a mix of the ServletContext log and System.out, neither of which is
appealing to me.
> My intention is now to wait for feedback, make necessary
> improvements and then commit this software to
> jakarta-velocity-tools within about a week.
>
> My next planned steps are the following:
> - setup test cases
> - add documentation: overview, user guide, quick reference guide
> - make documentation printable
> - put together a binary distribution with examples and a blank
> application and announce it to the world
> - add ActionMessagesTool
> - rework the current logging concept for context tools
> - add capability to config Velocity
i really look forward to this!! IMO this is one of the biggest things
missing. i've entertained the idea of finding some time to add this to the
velocity view stuff myself. i may still...
> - remove Velocity's [INFO] logging for each template
>
>
> Your feedback is appreciated.
hey, it's the least we (i?) can do. i really appreciate all the work you've
put into organizing and developing this!
> Gabe
>
> --------------------------------------------------------------------
> API Changes in 0.6:
>
> - MessageTool
> - Added method public get(String key, ArrayList args). It's more
> Velocity compatible than get(String key, Object[]). I left
> the latter to stay compatibility with existing apps.
+1 actually, since this is a tool specifically for use in Velocity
templates and we're changing most things anyway, i think perhaps we should
remove the get(String,Object[]) method altogether. i know i'm certainly not
dependant on it.
> - LinkTool:
> - Renamed setPath() to setURI(). This method takes absolute
> URIs, server-relative URIs, relative URIs and URIs with query
> parameters. The new name is more accurately reflecting what the
> method does.
> - Renamed getServerPath() to getContextURI(). This naming is
> consistent with the naming used in the Servlet API and it seems
> also more intuitive.
> - Added method getContextPath(). This is a natural complement to
> method getContextURI()
> - I based my implementation of LinkTool on the implementation
> contributed by Nathan. I changed the following aspects:
> - Added support to work with relative URIs (in addition to
> absolute URIs)
> - Added support to work with URIs that point to other servers
> - Added support to resolve Struts action names to URI references
> - Added support to resolve Struts forwards to URI references
+1
> - ErrorsTool:
> - Added method public boolean exist(String property). This is a
> natural complement to public boolean exist().
> - Changed methods get() and getAll() to return ArrayLists instead
> of HashMaps. With ArrayList the sequence of error messages is
> maintained. This was not the case before.
ick. that kills the option of doing things like
$!errors.login_errors.invalid_username
and basically forces people to loop over errors like
#foreach( $error in $errors.login_errors)
$error
#end
or do something truly evil like
$errors.login_errors.get(0)
instead of allowing them to access individual messages directly by their
key. so, i find myself conflicted. i agree, we need to have the errors
maintain their order, but i'm loathe to give up direct access by key.
perhaps we need to consider returning a Map or List class of our own that
would maintain the order and still allow get(key) access.
> - Introduced methods getMsgs() and getMsgs(String property). These
> two methods generate the necessary markup to display error messages
> in the view. All the markup is configurable in the message
resources.
> We discussed previouly to skip these methods and instead recommend
> the use of a macro to render error messages.
> While creating some examples for the documentation I realized that
> it is very painful to have to write a macro each time you
> want to render some error messages. Displaying error messages is
> such a basic and frequently needed feature that I feel we need to
> provide basic support for it in the ErrorsTool. It is still
> possible to use macros to custom format error messages.
-1
ok, i fully agree that it is ridiculous to write an #errorMarkup macro for
each template, but this is why we need to allow for Velocity configuration.
the #errorMarkup velocimacro should be a global macro so that you need only
write it once. still, even as things presently are, you can write it in a
template on it's own and #parse that template at the top of any other
templates you need it in.
if you insist, then i suppose i can abide the presence of these methods
until the time that such velocity configurability is added :-). but i think
at the very least, these methods should be surrounded by glaring warnings of
their future demise to discourage any new users to become reliant upon them.
i'm REALLY not a fan of adding this functionality.
> - FormTool:
> - Added method getTokenName() to retrieve the request parameter name
> that must be used for the transaction token. This is necessary to
> be able to handle the transaction token.
+1
> - ActionMessages:
> - Not implmented yet. This is a feature of the upcoming Struts 1.1
> release. I need to study this in more detail to really understand
> what the intended behavior is in relation to the ErrorMessages
yeah, makes sense to wait for 1.1 at least. i'm still fuzzy on this too.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity for Struts
Posted by Incze Lajos <in...@mail.matav.hu>.
> > Struts has no concept of logging????
>
> Standard Struts relies on the logging facilities provided by the servlet
> API. It adds a thin layer that supports log levels (as a log() method of the
> Struts servlet). There's now some discussion on the dev list about adding
> the commons logging.
Recently the commons-logging was introduced in the head branch.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity for Struts
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/5/02 8:39 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> "Geir Magnusson Jr." wrote:
> [..]
>>> The code is now structured such that all Struts Know-How is
>>> kept in a class StrutsUtils. This is a utility class with all
>>> static methods. All context tools use it to access to the
>>> Struts resources. This avoids the spreading of Struts Know How
>>> all over. The methods of StrutsUtils reflect what Velocity context
>>> tools need from Struts. I hope that at some point these
>>> utilities can be integrated into Struts itself.
>>
>> It would have been cuter if you called it 'StrutsKnowHow'.
>
> Are you serious? :-) This sounds a little awkward...
No, not serious :)
--
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: [VelTools] Velocity for Struts
Posted by Gabriel Sidler <si...@teamup.ch>.
"Geir Magnusson Jr." wrote:
[..]
> > The code is now structured such that all Struts Know-How is
> > kept in a class StrutsUtils. This is a utility class with all
> > static methods. All context tools use it to access to the
> > Struts resources. This avoids the spreading of Struts Know How
> > all over. The methods of StrutsUtils reflect what Velocity context
> > tools need from Struts. I hope that at some point these
> > utilities can be integrated into Struts itself.
>
> It would have been cuter if you called it 'StrutsKnowHow'.
Are you serious? :-) This sounds a little awkward...
>
> >
> > I introduced an abstract context tool ServletContextTool. All
> > Struts context tools extend ServletContextTool. It provides
> > logging to the logging facility provided by the Servlet API.
> > I am not fully satisfied yet with this approach. I think we
> > should forsee logging support already in the ContextTool interface.
>
> Struts has no concept of logging????
Standard Struts relies on the logging facilities provided by the servlet
API. It adds a thin layer that supports log levels (as a log() method of the
Struts servlet). There's now some discussion on the dev list about adding
the commons logging.
But, how do context tools get access to the logging facilities? That's
not straightforward. The current ContextTool interface doesn't forsee
anything.
One approach would be to add a setLogger(Logger l) method to the
ContextTool interface. A context tool manager, like VelocityViewServlet,
could then use this method to pass a reference to a logger. Such an approach
wouldn't be specific to a servlet environments.
Gabe
>
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> The question is : What is a Mahnamahna?
--
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: [VelTools] Velocity for Struts
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/5/02 6:12 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Hi,
> based on the discussed API for Velocity for Struts I implemented
> the context tools. I have put together a demo application that
> incudes several small application examples as well as reference
> documentation for the context tools. The demo can be downloaded
> from
>
> http://www.teamup.com/velstruts/velstruts.war [1.3 MB]
>
> This is a ready-to-deploy war file. Put it into the webapps
> directory of your favorite servlet container and restart. Then
> point your browser at http://yourserver:port/velstruts/
>
> While implementing the API I came across several weaknesses of
> the discussed API. I made the changes outlined below. Please review
> and yell if you feel something is going the wrong way. Please refer
> to the reference documentation in the war files for details.
>
> The code is now structured such that all Struts Know-How is
> kept in a class StrutsUtils. This is a utility class with all
> static methods. All context tools use it to access to the
> Struts resources. This avoids the spreading of Struts Know How
> all over. The methods of StrutsUtils reflect what Velocity context
> tools need from Struts. I hope that at some point these
> utilities can be integrated into Struts itself.
It would have been cuter if you called it 'StrutsKnowHow'.
>
> I introduced an abstract context tool ServletContextTool. All
> Struts context tools extend ServletContextTool. It provides
> logging to the logging facility provided by the Servlet API.
> I am not fully satisfied yet with this approach. I think we
> should forsee logging support already in the ContextTool interface.
Struts has no concept of logging????
--
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>