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