On Fri, May 02, 2008 at 07:25:01AM -0700, David Chang wrote: > > I have the bad feeling about this way of validation > > 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. >
I think you'll find the Wicket team has very strong aversion to doing things declaratively rather than with Java code. The problem is that with declarative approaches, once you step outside of the use-cases envisioned by the designer of the declarative system things become much more difficult. > 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. Wicket doesn't come with a client-side validation framework by default; however, the validators have an opportunity to participate in the component rendering, so it wouldn't be too tough to create your own set of validators that also rendered the appropriate Javascript to do client-side validation. > 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. A Wicketer would view it differently: in Valang+Spring MVC you have Java code for your controller and validation "code" in XML, whereas in Wicket it's all in Java code. That said, it probably wouldn't be too hard to implement a FormValidator that accepted valang syntax and applied it to a form. > So in terms of elegance, productivity, management, > ..., I am not sure Wicket's is right. > > 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? Weird. Your experience is exactly opposite to mine. I found Spring MVC to be hopelessly scattered: declarations in XML, controller code in Java, view code in templates. In Wicket, I can create self-contained components, each including all the functionality, markup, validation, JS, etc. it needs to get along in the world. I can then stitch these components together into pages that can be re-jigged and reorganized very quickly. It feels to me like Wicket allows me to work at a higher level of abstraction, while with Spring MVC I was always down in the weeds dealing directly with the request/response cycle. jk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
