Re: object sharing between pages
the problem is that if you have 2 page that share the same object instance and 1 of the pages get serialized and then deserialized The object instance is not the same anymore For example this still works: Object A instance PageA has that instance. PageA creates PageB and passes that instance (and itself) PageB is rendered Action executed on PageB PageB sets an internal variable on Object A and then sets PageA as te response page. This only works if the session is not replicated and the Action on B is executed on a different machine. But if somebody goes from PageB to PageC and then uses the back button to get to B and then executes the action The shared instance is not shared anymore (just as session replication) So the best thing is that you shouldnt depend on shared variablen. On Thu, Mar 13, 2008 at 10:42 AM, Maurice Marrink [EMAIL PROTECTED] wrote: Why shouldn't pages share objects? pushing object x from page a to page b to modify x and then return to either the same or another instance of page a is just fine. You can also wrap object x in a model and use that same model on different pages / components. Maurice On Thu, Mar 13, 2008 at 10:14 AM, Frank van Lankvelt [EMAIL PROTECTED] wrote: Hi, please excuse my newbie question; is it correct that pages cannot share objects? (any pointers on the subject of wickets serialization would be greatly appreciated) I want to provide some feedback to the main page from a modal-window, and now do this by putting meta-data in the session. Is there a cleaner way to do this? thanks, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
Maurice Marrink wrote: Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: object sharing between pages
Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared how can this be? Aren't different pages written to different streams and thereby incapable of sharing objects? But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! ok, I'll go ahead with storing the object in the session directly (as meta-data) and use models in the pages to access this object. cheers, Frank Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
Sebastiaan van Erk wrote: Maurice Marrink wrote: Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. Actually, that's how serialization would NORMALLY work. :-) I'm not really 100% sure how Wicket serialization works (I believe a referenced page is not serialized inline, but instead a page id is written, which could mean you always get copies of your instances on deserialize, but then again I'm not sure). In either case, even with standard serialization you would have issues... But to be honest I've never really run into this issue with Wicket at all... When do you have *instance* variables in a page that point to shared objects which are not immutable? I hardly have any instance variables (other than maybe a few Components and Spring beans). Regards, Sebastiaan So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: object sharing between pages
Frank van Lankvelt wrote: Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared how can this be? Aren't different pages written to different streams and thereby incapable of sharing objects? Yes, I believe you are correct. But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! ok, I'll go ahead with storing the object in the session directly (as meta-data) and use models in the pages to access this object. May I ask what your use case is? Regards, Sebastiaan cheers, Frank Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: object sharing between pages
yes Pages are not serialized in 1 go They are seperated from each other and saved as there own entity thats why you have that shared instance problem On Thu, Mar 13, 2008 at 12:40 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Sebastiaan van Erk wrote: Maurice Marrink wrote: Assuming B has a reference to Page A, wont A be Serialized with B, when you go to C, and both still share the same serialized object? When B is serialized, so is A, and serialization makes sure the instances to your object are kept shared But when A is serialized alone (and if A does not have a reference to B), then when A is deserialized you'll have a copy of the instance you gave to B and the reference is no longer shared. Actually, that's how serialization would NORMALLY work. :-) I'm not really 100% sure how Wicket serialization works (I believe a referenced page is not serialized inline, but instead a page id is written, which could mean you always get copies of your instances on deserialize, but then again I'm not sure). In either case, even with standard serialization you would have issues... But to be honest I've never really run into this issue with Wicket at all... When do you have *instance* variables in a page that point to shared objects which are not immutable? I hardly have any instance variables (other than maybe a few Components and Spring beans). Regards, Sebastiaan So the best thing is that you shouldnt depend on shared variablen. Ok so there are a lot of gotchas :) Yep! Maurice - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
ok, I'll go ahead with storing the object in the session directly (as meta-data) and use models in the pages to access this object. May I ask what your use case is? it's very simple; when carrying out an action on page A, I want to display a modal window (are you sure? with ok/cancel). The modal window creates a separate page, B, with the label and the buttons. The information (a boolean) about what option was chosen determines what to do on page A when the modal window is closed. cheers, Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object sharing between pages
Frank van Lankvelt wrote:
ok, I'll go ahead with storing the object in the session directly (as
meta-data) and use models in the pages to access this object.
May I ask what your use case is?
it's very simple; when carrying out an action on page A, I want to
display a modal window (are you sure? with ok/cancel). The modal
window creates a separate page, B, with the label and the buttons.
The information (a boolean) about what option was chosen determines what
to do on page A when the modal window is closed.
cheers, Frank
Ok, that definitely seems like something you should *not* be using the
session for. I'd think that's what you normally use a callback for, but
unfortunately I don't know how in Wicket (not without using shared
state), because for example, the onClose() method does not pass you the
contents of the ModalWindow...
I mean, you could do something like this if the contents were given back
to you:
modal1.setWindowClosedCallback(new ModalWindow.WindowClosedCallback()
{
// Hypothetical callback with extra contents argument...
public void onClose(Component modalWindowPage,
AjaxRequestTarget target)
{
boolean myBoolean = myModalWindowPage.getResult();
// do whatever with the result...
target.addComponent(result);
}
});
When I look at the Wicket examples for ModalWindow there is actually
shared state passed between pages (i.e., the page with the modal window
is passed as a parameter to the page IN the modal window). The modal
window page then calls methods (setResult(...)) to change the state on
the page that opened the modal window
I'm wondering now if this is safe in combination with serialization, if
so, why, and if not, what is the proper way to do this, because via the
session is awful.
Regards,
Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
