> 1. It is too much coding. Anybody used Valang in > Spring Module? By using Valang, the validation code is > much clean and a lot fewer and you dont need to create > a class simply for this simple validation.
The example you quoted is an example of a reusable validator that checks the values of two components with each other. It's probably a rare case to create a reusable validator for it, as you can achieve the same thing with fewer lines of code by just performing the check on your form's or button's submit method and then setting the error on failure. But the choice is yours whether you want the validation to be reusable (which also means it will be easier to move around in your code) or whether you just implemented quick and dirty (like I often do). Btw, team members, this comment can be found in IFormValidator: * TODO post 1.3: remove validate(form) *make IFormValidator extends IValidator where IValidatable's * value is form.modelobject and error reports on form - that way IBehaviorProvider can extend * IValidator > 2. Valang covers both client AND server-side > validation. Please note that client-side validation is > equally important as server-side's. I feel it is a > must for web apps in terms of user experience. It is very important that the server-side validation is robust, since the client-side can be messed with. Whether client-side validation is important depends... I typically use Ajax if I want checking on the fly. Very easy to implement using Wicket. But if you want client-side validation, you can create a combined validator and behavior (that would contribute the JavaScript code to the client), e.g. by letting your validator implement IValidatorAddListener and adding the behavior (possibly itself) to the component in the onAdded method. Would be fun if someone would pick this up and extend some of the simple validators we have with this. > 3. In Valang + Spring MVD, you have all the validation > code for a form in one place in stark contrast to > spreading it in "controller" code as in Wicket and > mixing validation code with visual manipulation code. > Valang's way is much easier to understand and > management. I don't know Valang, so I'm not sure what you mean. Anyway, you have plenty of choices to hide validation code if it bothers you. Examples are the automatic assignment of validators based on Hibernate annotations like we're doing in the project I work on (done via IComponentOnBeforeRenderListener), or custom components that assign validators to self in their constructors. Personally, I think Wicket's solution to validating components is quite nice as long as the validation is related to one component. If not (multiple components are non-related), it gets more messy, but I can't imagine that would be much better in other frameworks. > So in terms of elegance, productivity, management, > ..., I am not sure Wicket's is right. I think it is if you use your creativity and OO skills to make it fit your style. > Can Wicket provide a better solution? > > I would like to share my concern regarding the > Wicket's WebPage, where you put a form's code for some > visual aspects, validation, ajax, etc. in one place. A > big object. I feel it is too ambitious and it looks > like spaghetti code and mixes concerns/modules in one > place. Comment? Much to debate here, and there are plenty of discussions of the pros and cons to be found on the internet. You don't have to put everything in place; again use your OO skills to make it more elegant. Furthermore, the fact that so much is statically typed Java code that is also stateful makes that it is easy to maintain/ refactor/ navigate/ explore/ debug compared to declarative frameworks. Declarative frameworks often can result in less code, but typically only for relatively simple things, and you won't get any of the advantages of working with statically typed code. Also, a declarative framework - a DSL in fact - can never be as flexible as a general-purpose language. Wicket is very flexible because of that. Whether limitations of declarative frameworks hit you of course depends on what you're doing with it. Good luck, Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
