• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mixing Direct Actions and maintaining session state - SOLVED - is this a bug?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mixing Direct Actions and maintaining session state - SOLVED - is this a bug?


  • Subject: Re: Mixing Direct Actions and maintaining session state - SOLVED - is this a bug?
  • From: Riccardo De Menna <email@hidden>
  • Date: Fri, 9 Apr 2004 16:13:03 +0200

I seem to have solved my problem.

It appears that the problem is the "WOActiveImage" element. In fact, I was using direct actions linked through WOActiveImage elements.
If you use a simpler WOImage enclosed in a WOHyperlink, it works.


Is this some kind of bug or is there some details on WOActiveImages that don't allow for session preservation with directActions?

Riccardo

On 09/apr/04, at 11:34, Riccardo De Menna wrote:

Hi there,

I'm currently having problems in managing a directAction based application that uses Sessions as well.
I've found more than one topic in the list regarding this stuff but nothing that addresses this problem directly.


I've added a NSLog line in my Session constructor to check when a session gets created and then I've prepared a bunch of directAction linked pages.
It is in fact true that IF THERE IS a session, the directAction URL features a nice wosid=<the_id_here>, but this does not seem to be enough. When the new page tries to refer to the session through WOComponent's session() method, e new one get created instead of using the original one.


For what I've read in this topic, it should not be this way. The new page should see the sessionID and restore the old session.

I've also tried a workaround but without success... I've modified my directAction to something like this:

public WOComponent SampleAction() {
WOComponent nextPage = pageWithName("Sample");
String sessionID = getSessionIDForRequest( request() );
if ( sessionID != null ) {
Session restoredSession = (Session)(nextPage.application().restoreSessionWithID( sessionID, context() ));
nextPage.takeValueForKey( restoredSession , "session");
}
return nextPage;
}


But restoreSessionWithID returns a null...

Maybe I've missed some tweak somewhere that tells directAction pages to search for their session in the wosid part of the url.

Can anybody help?

Riccardo



On 05/nov/03, at 23:40, Karl Gretton wrote:

Thanks....I think that the WOHyperlink may not have been used. I will give this a try.

It worked with the cookie anyway....I just hoped that there would be a simple way to do it with a URL only...

..and there is! How typical of WebObjects to have something that just does it with no effort!

Karl

On Nov 5, 2003, at 12:59 PM, email@hidden wrote:

On Wed, 05 Nov 2003 05:59:37 -0500 Karl Gretton wrote:


Using URL-based session state, the session context is lost when moving
between DirectAction pages and regular WO pages.

This is not supposed to be so. A direct action URL _can_ have a
sessionID in the URL. It appears as a key/value on the end of the URL,
like: "?wosid=[sessionID]". "wosid" is the key. If you generate a
DirectAction URL from WOHyperlink, WOHyperlink should automatically
append this if and only if a session is present (if it's not, it's a bug,
but one you can work around manually if you need to). If you are
generating your DA URLs in some other way, it's easy enough to write code
which appends this value on the URL if and only if there is a session
(hint: context().hasSession() will check if a session already exists).


So either of the options you identify is possible and supported by Apple.
Option #2 ("Pass the sessionID in the URL between DirectAction pages, but
don't require it") is supposed to be automatically done for you by WO.
Option 1, putting the sessionID in cookies, will also work. Either way,
whether the sessionID is in a cookie set up according to WO conventions,
or in the URL according to WO conventions, the DirectAction pages should
pick it up if it's present (and them pass it on to generated URLs), and
not mind if it's not present. It ought to basically just work, just the
way you've described it.


--Jonathan



What solutions have people found to this? We have two ideas and would
like to have other peoples comments on them:-


1) Force WO to use a cookie for maintaining session state. While the
DirectAction pages will ignore this (will they? or is there someway to
still get at the session even though this is a DirectAction?) the
session should be preserved when the user selects a link to a regular
session-based WO page.


2) Pass the user's session ID around in the URL between DirectAction
pages but don't require them. Therefore, the DA pages will still work
for people without a session and of someone bookmarks the page, somehow
the DA page can ignore the session and/or pass the session information
to regular pages/


Any other ideas or comments?

Karl
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Mixing Direct Actions and maintaining session state - SOLVED - is this a bug?
      • From: Chuck Hill <email@hidden>
References: 
 >Re: Mixing Direct Actions and maintaining session state (From: Riccardo De Menna <email@hidden>)

  • Prev by Date: RE: validateAttribute custom error Message Not Showing Up
  • Next by Date: RE: Printing....
  • Previous by thread: Re: Mixing Direct Actions and maintaining session state
  • Next by thread: Re: Mixing Direct Actions and maintaining session state - SOLVED - is this a bug?
  • Index(es):
    • Date
    • Thread