auto-generation of anything is a horrible idea. it's a computer-driven violation of the DRY principle and you'll get what you deserve. there are pretty much always smarter approaches than code generation.
you ought to be able to use wicket to create a constraint driven validation system that does: - client side validation - server side validation - database validation - automatic limits unit testing we did the last 3 at thoof, and while the client-side validation was not a goal, it should be possible to integrate and drive a JS validation lib using the same annotations. David Chang-5 wrote: > >>>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. > > I would like to think practical. How many such > unexpected situations would happen? Besides, you can > always code extra validation in Java in controllers > using things such as Wicket's form validators. > > > >>>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. > > I really want to see such a thing in place. > Auto-generation of client-side validation code, IMHO, > is a much needed thing. At least, Wicket should have > this capability. It would be nightmare to wrtie > validation twice: one for the WebPage, one for > client-side validation. > > > >>>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. > > I dont have any real experience yet. It is mere my > observation and thinking. I am learning but still > evaluating. > > One thing I have is really the opposite to your > experience. I feel this "scatter" is not hopeless; but > it is a nice separation of concerns. Think about it. I > have no objection to puting everything in WebPage, but > these different concerns should be separated in Wicket > somehow, code should look clean and good... > > Thank you for sharing your thought and experience, > which is immensely helpful! > > Regards. > > > > > > > ============ previous emails ============= > > > > --- John Krasnay <[EMAIL PROTECTED]> wrote: > >> 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] >> >> > > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Advisory-question-tp17017178p17022968.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
