because of this i like to have a some kind of preference.
I do want versioning of all my state changes of component (remove/add or visiblitiy that kind of stuff)
But i am mostly not interested in versioning model data. Because that is mostly database data anyway (So it is "versionend" in the database)

Ok sometimes it is nice for example a User edit page where the model is the userid and i first show id 10 then 11 and if i then do back it would be nice
that i also work on id 10 instead of 11....

Maybe we should build something that it is easier for models to version themselfs. Like an interface IVersionable with a method Serializeable getVersionData()
Which a model can implement. And then we don't store the complete model but only that data.

johan


On 12/2/05, Nathan Hamblen < [EMAIL PROTECTED]> wrote:
This came up before when I was trying to track down why reversing the
sort order of a DataView was bringing down my test application.
(http://thread.gmane.org/gmane.comp.java.wicket.user/4309) It turned out
that the page versioning code was serializing the entire view hierarchy,
recursively, because of anonymous model classes that contained pointers
back into the view.

The consensus was that you would have to turn off page versioning if you
wanted an anonymous IModel. Is this still the case? I'm just now
noticing anonymous IModels becoming sort of recommended. Does that mean
than page versioning is not recommended anymore?

I'll admit don't even understand how versioning is supposed to work.
DataView sorting seems to be one of the few things that triggers it.
I've got forms updating models all over the place and nary a version to
be seen. So, I just turn it OFF then, and anonymously subclass IModel to
my heart's content?

Nathan

Christian Essl wrote:
> On Thu, 1 Dec 2005 14:24:20 -0500, Andrew Berman <[EMAIL PROTECTED]>
> wrote:
>
>> Honestly, I don't think there ever was a Spring Integration problem.  I
>> think people were just looking for a cookie-cutter approach to using
>> Spring
>> within Wicket.  It's actually quite easy to do without using any of the
>> Spring stuff that Igor and others wrote, but it's always a good thing to
>> have a common approach that everyone can follow.
>
> Honestly, I think Igor did a good job: It is just easier and more
> natural to write over and over again:
>
> new HibernateModel(obj,_dao);
>
> than
>
> new HibernateModel(obj, new Model(){
>    getObject(Component comp){
>       return ((MyApplication)Appliation.get()).getDAO();
>    }
> });
>
> and this is not restricted to HibernateDAOs but to any bean you do not
> want to get serialized whtih your components.
>
> Christian
>
>
>
>
>
>
> ___________________________________________________________ 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



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

Reply via email to