where are you talking about?
I was talking about the models under the form components which now are not causing a model change even if new data is comming in
but if we do a complete capture i see those model changes and i say "he it is changed, now create a new version of the page"
johan
On 9/19/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
hmm but form components are written by us, we can make those fields transient?
i dont know, for 2.0 it might be cool to just clone the page every time - we already do this anyways when storing to disk. the change thing is pretty error prone and hard for n00bz and even not so n00bz. the other big plus is that we really have _transparent_ back button support. but it might be too damn expensive if they dont want to use the disk - but maybe not?
-IgorOn 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:and there is another problem with the automatic-versioning-that-would-make-your-life-as-a-wicket-developer-much-more-easier
because now form components don't do version of there models.. Because it is data and we most likely don't want to version that
But with our automatic-versioning-that-would-make-your-life-as-a-wicket-developer-much-more-easier we encounter those models
and see changes (could be) but in the current way we wouldn't see that as a change and now we do..
So i still think we need to keep the current addStateChange but the object graph "serialization" can still be used to do the model "cloning"
johan
On 9/19/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:yeah thats nice, but you just lost the flexibility of where the address can come from (no imodel indirection - yeah you can make yet another constructor) and more importantly the short hand compound property model notation. if i can use the notation on a textfield why cant i use it on my editor panel?
ok a constructor like this: AddressPanel(String id,IModel<Address> model) ?
yeah a constructor like that helps, but you still dont have the shorthand notation :)About the object-graph versioning. There is one small problem (yes i dreamt about this instead of hot chicks.. there must be something really wrong with me)
see, if i go to bed thinking about this stuff i end up not sleeping :) so helps to think about something else.We do the first graph when we take the page from the session (everything fully detached)
Then we call something on it..
Then we need to compare it, before it renders.. But how do we do that?
I don't want to detach everything. And can we compare a detached page with the attached version?
Then we must make sure that the attached version only alters transient fields.. If not then we have a problem...
well this is a pretty big problem i would say. i guess there goes that idea. i really dont want to impose transient on users because you know they will forget, and then we end up storing a lot of extra. so i guess no automatic-versioning-that-would-make-your-life-as-a-wicket-developer-much-more-easier unless we really clone the entire page every time and shove it to disk.
-Igorjohan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
