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