I think they are wicket-specific, because where outside of wicket would
you need a wicket interface?
And if you implement it yourself you will have to think of versioning,
otherwise you will have to think of versioning everytime you just use
it.
For now I'd say have for POJO IFilterLocator a
rememberVersion(IStateRecorder) method (but name it different) Than it
is
explicit what is going on and it is easier to use. (The same could be
done
for ISortState). (Again IFilterLocator should take a Serializable and
maybe Ojbects.clone() could check if the cloneable implements Cloneable)
Generally I think IModels which need versioning and the underlying
object
does not do it itself (which POJOs) should implement an interface and
this
should be as:
IPOJOVersionable{
rememberVersion(IStateRecorder recorder);
}
The user than has to call this method on the Model.
I think this is better because:
a) it is more explicit. which ordinary user - like me knows - what is
going on in modelChanging()
b) currently only the model gets cloned which for pojos only has an
effect
if you use a model with a non transient reference
c) you can not share the same underlying POJO instance between different
components because after the roleback you will end with two instances
(transparently)
d) I often use more than one POJO ie in a Form so if I need versioning I
want to version them both without the need of an extra component for
registering the Pojo.
Christian
On Tue, 6 Dec 2005 15:36:55 -0800, Igor Vaynberg
<[EMAIL PROTECTED]>
wrote:
> I guess the question is do we want to infact make it something
> wicket-specific. right now its just an ordinary pojo you can use
anywhere
> you like. but if we roll the versioning logic into it, it really does
> become
> locked to wicket. that is why i struggled to find a way to keep
> versioning
> out of it - it allows users to work with simple pojos.
>
> by keeping it an pojo there is another advantage - it is easier to
expand
> on. For example IFilterLocator works with ordinary objects that are
used
> as
> a model for the filter form. everytime you write a filter model
> (normally a
> simple bean) do you want to deal with versioning everytime or would
you
> rather let the filter toolbar do it for you?
>
> by keeping the versioning out of models we shift the versioning into
> toolbars. most users will use toolbars and not create them so i think
its
> better to keep stuff like that out and let the users who create
toolbars
> know that they should version the model they are provided if they want
> the
> backbutton to work - but that is not any different then creating any
> other
> custom component that modifies data - so this isnt even anything
special
> about toolbars.
>
> -Igor
>
>
>
> On 12/6/05, Christian Essl <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, 6 Dec 2005 12:25:23 -0800, Igor Vaynberg
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>> > So to summarize your idea it would be like this
>> >
>> > class SingleSortState
>> > IChangeRecorder recorder;
>> > SortState(IChangeRecorder) {...}
>> >
>> > setPropertyState(...) {
>> > recorder.addChange( new Change() {...} )
>> > }
>> >
>> > OrderByLink { onclick () { getState().setProperty(...); } }
>> >
>> > this has the same net affect as
>> >
>> > OrderByLink { onclick() { addstatechange(new Change() { ...
>> > clone(getState()); }); getState().setProperty(...); } }
>> >
>>
>> Right.
>>
>> >
>> > Your way shifts a lot more responsibility into the model because it
>> > needs to
>> > know how to version itself, and most models in wicket need to do
that
>> to
>> > support the back button. That means you can no longer user your
pojo
>> > models
>> > as wicket models. for example i can no longer reuse my Person pojo
>> from
>> > the
>> > domain layer because it has no concept of versioning. am i totally
off
>> > here?
>> > Thats the advantage of doing it on component side - your models can
>> stay
>> > dumb pojos and the component takes care of versioning them by using
>> the
>> > only
>> > fool-proof way it can - cloning.
>> >
>> > -Igor
>>
>> You are right I definately went too far. ModelChanging triggers a
>> versioning clone - did not know that. Propably I did not see it
because
>> I
>> mainly use my Pojos from the DB and I do not version them. Thanks for
>> the
>> advice I now understand versioning a bit better.
>>
>> But back to the SortState: I think for such Wicket only models it is
>> still
>> more convinient to do it directly inside the model. In the end you
will
>> have to 'version' it somehow and while you are right that the only
entry
>> is through a component there can be many entry-points. And than it
is a
>> good candidate to refactor it in one place - why not the model?
>>
>> Christian
>>
>> --
>> Christian Essl
>>
>>
>>
>>
>>
>> ___________________________________________________________
>> Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
>> anmelden: http://mail.yahoo.de
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
log
>> files
>> for problems? Stop! Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>
--
Christian Essl
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
