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
