I have to admit, I don't remember the Observer pattern very well ;-)
But if I don't make any mistake, the "separate thread's monitoring class" you talk about is where my WOLongResponsePage's performAction is executed. And to be an Observer of the Session, it needs to have access to the Session doesn't it?
And it is what I can't manage to do without having an error in the console :-(

Fabrice


On Feb 7, 2006, at 7:17 PM, Kieran Kelleher wrote:

OK then, would the Observer design pattern not help? ....... with your separate thread's monitoring class being the Observer and the Session being Observable?

On Feb 7, 2006, at 10:23 AM, Fabrice Pipart wrote:

Actually, I just can't do that...
I don't really want to go into details but my WOLongResponsePage monitors a process that is NOT done in the performAction.
And actually it cannot be done in performAction.
It is done in a seperate thread that doesn't know anything about the WOLongResponsePage. Though it can access the session.

So, I think your proposition cannot help :-(

Thanks anyway !

Fabrice

On Feb 7, 2006, at 3:11 PM, Kieran Kelleher wrote:

Why not just stuff the values you need into a NSDictionary and push that into the WOLongResponsePage subclass after you create it and before you return it. Your performAction can then work with those values.

I use ERXLongResponse, but I am sure WOLongResponsePage works similarly in that the performAction runs on a separate thread to the worker thread running the R-R loop. The pageForResult and pageForException execute in the R-R loop thread. So if you are working with POJO's then just push them into the WOLongResponse page so that performAction has easy access and make sure your POJO methods are thread safe (synchronized) if required. If you are working with EnterpriseObjects, then you _should_ create a separate editing context at the beginning of your performAction, lock the EC, and make localInstance copies of any EOs you plan to manipulate inside the performAction method. Something like this:
ec.lock();
try {
   // Make localInstance copies of EO's in the new EC.
       blah, blah, blah
      do EO manipulation in the performAction


        ec.saveChanges();
} finally {
      ec.unlock();
 }

HTH,

Kieran

On Feb 7, 2006, at 7:41 AM, Fabrice Pipart wrote:

Hi !

I am having trouble in the implementation of a WOLongResponsePage subclass.
I would like to access the session of my user in the performAction method to check some values stored in it.
But when this is the second refresh of my page, I am out of the request-response loop and therefore, my context is null when I do a session() call.
I can still access the values stored in my session but I have an annoying message in the console.

Is there a way to store those values somewhere else than in the session?
Is there a way to access the session better than session()?
I have looked at WOSessionStore.checkOutSessionWithID but its second parameter is a request... I don't have any in performAction...

If someone could help...

Thanks

Fabrice



www.icconsulting.mc


International Corporate Consulting

Palais de la Scala

1 avenue Henri Dunant

Suite 1155

MC - 98000 Monaco


Skype: fabrice.pipart

Tel.  +377 97 98 21 04 (direct)

Fax. +377 97 70 88 07



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]


www.icconsulting.mc


International Corporate Consulting

Palais de la Scala

1 avenue Henri Dunant

Suite 1155

MC - 98000 Monaco


Skype: fabrice.pipart

Tel.  +377 97 98 21 04 (direct)

Fax. +377 97 70 88 07





www.icconsulting.mc


International Corporate Consulting

Palais de la Scala

1 avenue Henri Dunant

Suite 1155

MC - 98000 Monaco


Skype: fabrice.pipart

Tel.  +377 97 98 21 04 (direct)

Fax. +377 97 70 88 07



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to archive@mail-archive.com

Reply via email to