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