In this case one would have to use a Wrapper-Class which implements a
special interface Wicket
reacts on. Something like
class personeditor extends panel {
public personeditor(string id, person p) {
super(id, new DetachableWrapper(p)); // let DetachableWrapper
implement ModelWrapper
}
And then Component.getDefaultModelObject() reacts on ModelWrapper
interface (like on IModel now)
Object getDefaultModelObject() {
if (model instanceof ModelWrapper) {
return ((ModelWrapper)model).getObject();
} else {
return model'
}
But then personeditor would hard code the detachable stuff so for re-
usable components this solution
would be worse than the current one.
I must admit that I don't get the whole detachable stuff in Wicket.
I'm used to think in horizontal tiers
where one tier does all the caching "automagically" (e.g. 2nd level
cache in JPA/Hibernate) and the
other tiers don't know about that fact. In addition, I'm so used to
think in the request/response pattern
that the Wicket component model is really hard to get for me (never
did any Swing...)
On Oct 6, 2009, at 17:09, Igor Vaynberg wrote:
so if i have
class personeditor extends panel {
public personeditor(string id, person p) {..} }
instead of
class personeditor extends panel {
public personeditor(string id, imodel<person> p) {..} }
how do i implement the lazy loading behavior if the person has to be
loaded from the database?
-igor
On Tue, Oct 6, 2009 at 12:36 AM, Robin Sander <[email protected]>
wrote:
Ok, I overlooked that IModel extends IDetachable but besides the
detach()
method
- which would be a special model behaviour in my opinion - IModel
does have
two
methods only:
T getObject();
void setObject(final T object);
Where's the benefit of using
new Component<MyBean>("xy", new Model<MyBean>(myBean))
and then access the actual model (object) by using getObject()/
setObject()
instead of
new Component<MyBean>("xy", myBean)
and then having a field
T model;
which could be directly accessed? (or even wrapped if you want to
implement
additional
stuff)
A user may add still addional behaviour by implementing special
interfaces
like Detachable
or something. This approach looks more natural for me but I'm
asking more
out of curiosity...
On Oct 5, 2009, at 18:32, Jeremy Thomerson wrote:
On Mon, Oct 5, 2009 at 7:44 AM, Robin Sander
<[email protected]> wrote:
Another question because someone mentioned it in this thread and
I asked
this question myself:
why do we need an empty interface for Model? Why can't a mere
String or
any
serializable POJO be
used as a model? (than this discussion about the name would end
also...)
I'm not sure I understand what you're saying. IModel is currently
the
interface and is not an empty interface. And an instance of
IModel is a
data proxy / location service - not the actual data itself - which
is whay
any POJO can not be a model. The POJO is the model object.
--
Jeremy Thomerson
http://www.wickettraining.com
