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