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
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
