Hi!
Two design questions for experienced wicket users... Mail is a bit long.
I apologise for this, but I wanted to explain the situation well.
We have been using wicket now for a while, and I think it's time to try
to finally clean up our code a little. With that in mind, I have two
questions for more experienced users. First is about where to put logic,
second is about use of compound wicket models.
Background
----------
Let me begin by describing our model briefly.
We have a search engine that allows certain "controlled" queries, and we
have a model/controller to accompany the wicket component(s) for this.
Our idea is:
- extract the state only into a very simple, serializable bean
- use a controller to validate and control what state the
bean can be in
- "write" the state of the bean (query) in various formats
through the use of a QueryWriter object
- obviously use wicket component to allow user to set state
Our reasoning is:
1. Having a very simple and serializable bean will make it easy
to save the state either in a wicket session or in the backend.
The object should therefore be very lightweight.
2. Ideally NO logic should be in the wicket component. This is because:
a. Logic should not be in the view
b. Encapsulated logic can be reused (for example if we implement
in Swing)
3. Having a separate writer is a nice way to decouple the rendering
of the state of the bean and seems to work very well.
Our model ends up being a complex bean that looks something like this:
public class QueryObject
implements Serializable
{
private ChildQueryObject m_colors;
private ChildQueryObject m_dates;
...
// Getters and setters here
// No logic! Very simple
}
And each "child" query object above can look something like this:
public class ColorQueryObject
implements Serializable
{
private boolean m_isBlueSelected;
private boolean m_isRedSelected;
...
public void setBlueSelected( boolean isSelected)
{
m_isBlueSelected = isSelected;
}
...
}
... you get the idea.
As stated above, the idea is that these beans hold only the state, and
nothing more. The query is "printed" by the user of a QueryWriter, which
I won't get into here.
This all looks fine at first glance, but when we get into the details,
we are scratching our heads about a few issues, wondering which would be
the "best" way to move forward.
First Question: Controller Logic
--------------------------------
The idea of the controller is to control which states are valid, and
which are not. The original idea is that the wicket ui components can
only put the beans into a given state by using this controller. The
reason is that I don't like having too much logic in the ui classes.
If we do this, it looks like it means a lot of duplication of code,
since wicket will simply be delegating to the controller. For example:
In the wicket page, we'd have something like:
controller.setBlueChecked( isBlueChecked );
And in the controller:
public void setBlueChecked( boolean isChecked )
{
// validate if blue can be checked in this state
// set the value, and adjust state of other
// properties if necessary
// If it can't, what do we do? Throw an exception?
}
The idea sounds good, but I'm wondering if this is even necessary. It
was suggested to me that cleanly separating stuff into a controller is
not worth the effort, since we'd be "duplicating" so much code for no
good reason.
What do most people do to achieve clean code in this type of situation?
Also, say if we wanted to make the component compatible with
"bookmarkability", would it be a good idea to have a setter or
constructor in the controller that accepts something similar to
PageParameters, so wicket can just pass through that object to the
controller?
Second Question: Mapping Above Model to Wicket Models
-----------------------------------------------------
Since the model above is already established, I presume that we should
just be able to do something like:
IModel model = new Model( bean );
So now, the above bean is "wicketized".
However, two things I do not understand about this are:
1. How do we connect the wicket model with our controller
above when validating the state and delegating to the
state-holder bean?
2. How do we "associate" parts of the state-holder bean
with the wicket controls? For example, the "blue"
above needs a checkbox, so how do we associate the
value of blue in our bean above to the "blue" checkbox?
Hope my ramblings make some sense.
Cheers,
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
