Another way to handle this is to leverage the wicket validation process
by extending FormComponentPanel.
Your userEditPanel would be composed of individual textfields whose
models are not linked to your IModelUser. Then implement the
convertInput method that builds a new User object from the
Thank you all for the responses !
And if you have more ideas let me know !
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Using-Wicket-with-businness-model-classes-that-check-for-rules-tp3245298p3246809.html
Sent from the Users forum mailing list archive at
Hi all,
I'm new to Wicket.
I'm building an application, actually finished most of the businness model
classes.
My businness classes don't have a default constructor, they have a
constructor with parameters. Inside the constructor, it calls to the
setters. These have the business rules
What about having a Validatable interface instead? I realize that
this would allow you to put your business objects into an invalid
state, but it would help make things easier :)
On Fri, Jan 28, 2011 at 3:18 PM, fernandospr fernando...@gmail.com wrote:
Hi all,
I'm new to Wicket.
I'm
Thanks James that was a quick response.
The problem is that I already have many classes designed this way.
Also, the classes where created on purpose this way as an analysis/design
decision, I mean, only valid business objects should be created.
--
View this message in context:
Well, you could create your own BusinessPropertyModel class that
subclasses PropertyModel and catches those exceptions, perhaps. You'd
have to figure out an elegant way to propagate the error message to
the FormComponent that caused the issue. If you don't need
component-specific error messages
Thanks James I'll investigate on extending PropertyModel.
Currently I'm doing the following:
public class UserRegistrationPage extends WebPage {
@SpringBean
private UserService userService;
private FeedbackPanel feedbackPanel;
private UserDto userDto; // only
Just a suggestion, pass the UserDto to the service layer and let the
service layer do the conversion. Then you can look at a href=
http://code.google.com/p/simple-object-assembler/;Simple Object
Assembler/a to encapsulate the conversion. Hint: use
automapWhenNoConverterFound property and you
But, then you lose the component-specific error messages.
On Fri, Jan 28, 2011 at 4:08 PM, mzem...@osc.state.ny.us wrote:
Just a suggestion, pass the UserDto to the service layer and let the
service layer do the conversion. Then you can look at a href=
The problem with that approach is that you don't get all of the errors
at once. The user would have to submit, see an error, fix, resubmit,
see another error, etc.
On Fri, Jan 28, 2011 at 3:59 PM, fernandospr fernando...@gmail.com wrote:
Thanks James I'll investigate on extending
Right right right, good catch, but I suppose you could write a conversion
service which throws the business exception. Not really a solution to
your question, but it would clean up your code a bit and take conversion
logic out of the frontend.
From: James Carman ja...@carmanconsulting.com
I don't know that I would agree that the conversion logic needs to be
taken out of the front end. The front end is where the data is
collected. It may have to be collected in a specific way
(FileUploadField perhaps) that is connected with the chosen
presentation layer (Wicket in our case). It
Ok but if the conversion has to be done multiple times why not encapsulate
it and clean up your code, rather than coding a conversion for each dto
every time its needed. With my suggestion the frontend calls a service to
do the conversion, then supplies the primed object to the service to
13 matches
Mail list logo
