Hi,
When your page gets serialized (which can happen between requests),
transient fields (like the "future" field) are set to null.
When your behavior is triggered and the page is deserialized, the field
is null.
Met vriendelijke groet,
Kind regards,
Bas Gooren
schreef vp143 op 3-2-2014 15:
Yup that's exactly what I have done. My problem lies with the lock creation
in newEntityLock(PersistentEntity entity) which needs the session Id...
Chambre
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Accessing-WebApplication-from-the-service-layer-tp4664145p466415
I cannot get future here
(https://gist.github.com/jonnywray/636875#file-futureupdatebehavior-java-L31)
to have a value.
I do not understand when/how it gets deserialized?
Martin Grigorov-4 wrote
> Because it is transient:
> https://gist.github.com/jonnywray/636875#file-futureupdatebehavior-java-L
class MyApp extends WebApplication {
@Inject EntityLockService lockService;
@Override
public void sessionUnbound(String sessionId) {
lockService.cleanup(sessionId);
}
}
Martin Grigorov
Wicket Training and Consulting
On Mon, Feb 3, 2014 at 3:09 PM, ChambreNoire wrote:
> Yes however I also
Yes however I also store the id of the session that owns the lock in a map so
that I can easily flush locks when a user session expires. This would mean
that EntityLockService would need access to the current WebSession which
also seems messy...
Chambre
--
View this message in context:
http://ap
Well, you can either store it as application metadata or make your
locking service implementation a singleton (managed by your dependency
injection framework of choice).
Either way, you abstract away the exact storage location of your locks
behind the facade of your EntityLockingService.
Met
Hello,
OK so no storing my Map in the Application MetaData
then?
Many thanks,
Chambre
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Accessing-WebApplication-from-the-service-layer-tp4664145p4664147.html
Sent from the Users forum mailing list archive at Nabble.com.
Hi,
Extract the locking managing code in a service.
Then use Spring/CDI/Guice/... to manage the service dependencies for you.
Martin Grigorov
Wicket Training and Consulting
On Mon, Feb 3, 2014 at 2:38 PM, ChambreNoire wrote:
> Hey,
>
> I've just been sketching out an entity locking mechanism
Hey,
I've just been sketching out an entity locking mechanism (below) to prevent
users from editing entities which another user is already in the process of
editing. It works fine but the problem is that placing this in my
WebApplication class means that I need to make MyApplication.get() call fro
Because it is transient:
https://gist.github.com/jonnywray/636875#file-futureupdatebehavior-java-L19
After deserialization it will be null.
Martin Grigorov
Wicket Training and Consulting
On Mon, Feb 3, 2014 at 10:33 AM, vp143 wrote:
> Martin Grigorov-4 wrote
> > Hi,
> >
> > Create a panel that
Martin Grigorov-4 wrote
> Hi,
>
> Create a panel that has a child an image (the busy indicator).
> Add a timer behavior to this panel and check whether the slow operation is
> done and replace the image with another component that renders the new
> data:
>
> public void onTimer(AjaxRequestTarget
Thanks martin. It fixed the compilation issues for me. should try out
deploying the artifact.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Retrieving-the-submit-button-value-tp4664137p4664139.html
Sent from the Users forum mailing list archive at Nabble.com.
-
Cast frm.getRootForm().findSubmittingButton() to FormComponent
Martin Grigorov
Wicket Training and Consulting
On Mon, Feb 3, 2014 at 9:35 AM, chathuraka.waas
wrote:
> Hi,
>
> i'm trying to migrate my application wicket 1.4 to 6.13 and my earlier code
> has this code snippet to get the button va
Hi,
i'm trying to migrate my application wicket 1.4 to 6.13 and my earlier code
has this code snippet to get the button value.
frm.getRootForm().findSubmittingButton().getInputName();
but this is not possible with 6.13. is there a way to get the submit buttons
value for comparison.
Thanks in a
14 matches
Mail list logo