I didn't suggest improvements but second a question anotherone asked
in this thread.
And as a user I usually don't write re-usable components (in the sense
re-usable by other people),
so this is not my focus.
And regarding the excellent wiki page: that's one thing I don't like
about wicket. Documentation is
not were in belongs, in the code or at least checked in with the code.
I always have to figure
it out by myself if some wiki page is up-to-date or not.
I really never had such a hard time understanding a framework! (but to
repeat myself, I'm not used
to think in components when it comes to web design, so that's probably
just me)
Take for example Spring or Hibernate: the latest reference always
comes with the distribution and
the code is documented very well. (and maybe better aligns to my
thinking)
On Oct 6, 2009, at 18:54, Igor Vaynberg wrote:
so maybe, in the future, you can take the time to understand why the
things are what they are first and then suggest improvements :)
there is an excellent page about models on our wiki. have a look,
maybe it will make things clear.
-igor
On Tue, Oct 6, 2009 at 9:48 AM, Robin Sander <robin.san...@gmx.net>
wrote:
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 <robin.san...@gmx.net>
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
<robin.san...@gmx.net>
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
