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
>>>
>>>
>
>
