Re: validation: Wicket does the right thing? Or right tool?
Eelco, I am reading the PDF version of the book called Enjoy Web Development with Wicket. Basically it is a good one with many interesting examples, but these examples are simple and keep me wondering whether Wicket can handle other more complicated situations. I feel this book does a good tutorial job, but it has many how-tos and lacks whys (the Wicket design ideas). I feel switching from JSP+Spring MVC to Wicket it is crucial to know those whys to fully appreciate or effectively use Wicket. How is your Wicket in Action? Thanks, David I often have many questions when reading tutorials with simple examples. I wonder Wicket can do or how do more callenging/complex situations that I can easily handle with Spring MVC. --- Eelco Hillenius [EMAIL PROTECTED] wrote: Thanks so much for your input! I am still seriously learning Wicket now and will see if I will change my mind. BTW, what is the best Wicket example website? Best to download the Wicket examples distribution or check out from our subversion repo, so that you can browse through the source. And don't forget to search through this mailing list (archives) and look at the WIKI if you're stuck with something. I often have many questions when reading tutorials with simple examples. I wonder Wicket can do or how do more callenging/complex situations that I can easily handle with Spring MVC. You bet! There may be cases where using Wicket is overkill, but it certainly beats the hell out of competitors when it comes to handling complex cases. :-) You could download the first chapter of Wicket In Action (http://www.manning.com/dashorst/) to get our take on what exactly we're trying to solve (and what isn't solved by model 2 frameworks like SpringMVC and Struts etc) Cheers, Eelco Eelco - 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]
Re: validation: Wicket does the right thing? Or right tool?
How is your Wicket in Action? Download the first chapter and see for yourself :-) It's free after all, and no registration required (I think). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation: Wicket does the right thing? Or right tool?
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]
Re: validation: Wicket does the right thing? Or right tool?
Eelco, Thanks so much for your input! I am still seriously learning Wicket now and will see if I will change my mind. BTW, what is the best Wicket example website? I often have many questions when reading tutorials with simple examples. I wonder Wicket can do or how do more callenging/complex situations that I can easily handle with Spring MVC. Regards, David --- Eelco Hillenius [EMAIL PROTECTED] wrote: 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]
Re: validation: Wicket does the right thing? Or right tool?
Thanks so much for your input! I am still seriously learning Wicket now and will see if I will change my mind. BTW, what is the best Wicket example website? Best to download the Wicket examples distribution or check out from our subversion repo, so that you can browse through the source. And don't forget to search through this mailing list (archives) and look at the WIKI if you're stuck with something. I often have many questions when reading tutorials with simple examples. I wonder Wicket can do or how do more callenging/complex situations that I can easily handle with Spring MVC. You bet! There may be cases where using Wicket is overkill, but it certainly beats the hell out of competitors when it comes to handling complex cases. :-) You could download the first chapter of Wicket In Action (http://www.manning.com/dashorst/) to get our take on what exactly we're trying to solve (and what isn't solved by model 2 frameworks like SpringMVC and Struts etc) Cheers, Eelco Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
validation: Wicket does the right thing? Or right tool?
I am migrating from JSP+Valang+...+SpringMVC to Wicket
and am also still evaluting it. So far so good until I
saw this instance about using Form Validator to
validate two related form fields.
Problem (p81-82, book Enjoy Web Development with
Wicket, PDF version only):
Suppose a postage calculation form has two fields that
accept weight and patron discount code. For a
particular patron p1, you will never ship a package
that is weighted more than 50kg. Here is the code from
the book:
public class LightValidator extends
AbstractFormValidator {
private TextField weight;
private TextField patronCode;
public LightValidator(TextField weight, TextField
patronCode) {
this.weight = weight;
this.patronCode = patronCode;
}
public FormComponent[] getDependentFormComponents()
{
return new FormComponent[] { weight, patronCode };
}
public void validate(Form form) {
String patronCodeEntered = (String)
patronCode.getConvertedInput();
if (patronCodeEntered != null) {
if (patronCodeEntered.equals(p1)
((Integer)
weight.getConvertedInput()).intValue() 50) {
error(weight);
}
}
}
}
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.
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.
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.
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?
I am very new to Wicket and don't know the best ways
of using Wicket. I love to hear from expereinced
users/guru here.
Thanks for your input!
Warm regards,
David
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]
Re: validation: Wicket does the right thing? Or right tool?
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]
Re: validation: Wicket does the right thing? Or right tool?
don't agree at all of course. ;-) and i'm going to give you about the same
stock answer i always give: if you're repeating yourself, stop doing that.
writing redundant form code? writing redundant validators? think. use OO
design patterns. it's amazing what you can do with objects. at thoof i
never wrote validation code. we adopted the sun constraint library more or
less as described in this video:
http://londonwicket.org/content/LondonWicket-BeanEditor.mov
David Chang-5 wrote:
I am migrating from JSP+Valang+...+SpringMVC to Wicket
and am also still evaluting it. So far so good until I
saw this instance about using Form Validator to
validate two related form fields.
Problem (p81-82, book Enjoy Web Development with
Wicket, PDF version only):
Suppose a postage calculation form has two fields that
accept weight and patron discount code. For a
particular patron p1, you will never ship a package
that is weighted more than 50kg. Here is the code from
the book:
public class LightValidator extends
AbstractFormValidator {
private TextField weight;
private TextField patronCode;
public LightValidator(TextField weight, TextField
patronCode) {
this.weight = weight;
this.patronCode = patronCode;
}
public FormComponent[] getDependentFormComponents()
{
return new FormComponent[] { weight, patronCode };
}
public void validate(Form form) {
String patronCodeEntered = (String)
patronCode.getConvertedInput();
if (patronCodeEntered != null) {
if (patronCodeEntered.equals(p1)
((Integer)
weight.getConvertedInput()).intValue() 50) {
error(weight);
}
}
}
}
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.
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.
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.
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?
I am very new to Wicket and don't know the best ways
of using Wicket. I love to hear from expereinced
users/guru here.
Thanks for your input!
Warm regards,
David
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-tp17017178p17022506.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]
Re: validation: Wicket does the right thing? Or right tool?
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
Re: validation: Wicket does the right thing? Or right tool?
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: validation: Wicket does the right thing? Or right tool?
On Fri, May 02, 2008 at 09:13:40AM -0700, David Chang wrote: 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. I just realized that you may not be clear on the role of FormValidators in Wicket. A FormValidator is only used when the validation of one field depends on the value the user entered for another field. The vast majority of validation uses only field-level validators, which are much less verbose than FormValidators: new TextField(name).setRequired(true); new TextField(ccNumber).add(new CreditCardValidator()); My current Wicket application (~35,000 LoC, ported from SpringMVC BTW, so I speak from experience!) has no more than a handful of FormValidators. 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. In this case I think separation of concerns is just a nice way of saying lack of cohesion/encapsulation. I *want* my validation to follow my component around, especially when I have a form composed from several re-usable panels. Here's a real-world example. In my app we have a component that captures credit card info (card number, expiry, etc). It's not a form, just a Panel with a bunch of form components on it. We re-use this panel in several very different forms, each of which has various additional fields. Each time this panel is re-used, I just drop it into the form like this: form.add(new CreditCardPanel(ccModel)); I don't have to add the CreditCardValidator to each one of these forms. It comes pre-wired in the CreditCardPanel. have no objection to puting everything in WebPage, but these different concerns should be separated in Wicket somehow, code should look clean and good... Very few Wicket applications put everything in WebPage. Pages are usually componentized into various Panels, which in turn can be composed from other Panels and components. Each of these panels/components can come with their own validators, as well as with other contributions to the page such as JS, CSS, etc. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
