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.

 -Igor


johan


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

Reply via email to