Re: Using Static HREF - Session Problems
Re: Using Static HREF - Session Problems
- Subject: Re: Using Static HREF - Session Problems
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 16 Sep 2003 10:49:29 -0500
Yes. You are opening a relative URL. It is resolved in the context of the
current page's URL.
The current page's URL is a WO URL, which usually is of a form something
like this, for a component action based application.
http://hostname/cgi-bin/WebObjects/AppName.woa/wo/inh51GR12ItFoeb5aS9cMg/0.1.7.1.1
The relative URL 'calendar.html?something=something', in this context,
turns into:
http://hostname/cgi-bin/WebObjects/AppName.woa/wo/inh51GR12ItFoeb5aS9cMg/calendar.html?something=something
Looking at that, it's clear it's not a valid URL. Relative URLs are rarely
useful (they rarely produce something valid) in a WO application. I would
have expected this URL to result in a 'backtracked too far' error, rather
than a 'session expired' error, since there is a valid sessionID in that
URL, but "calendar.html" is not a valid contextID. But WO is a bit flakey
with which error page it generates sometimes, and at any rate we know
that's not a valid URL.
Good diagnosis on the development port for WO being used. I was scratching
my head over that one, until I saw your analysis. You could stop using
direct connect at all, and use a web server even in development, and then
your URL starting with '/' would work, assuming it pointed to a valid URL
on both your dev machine and deployment machine. Or you could use a URL
starting with http://hostname, yes. To avoid having to change this code at
deployment, you can write WO code to _generate_ this http:// URL,
automatically and dynamically inserting the proper hostname. You could keep
the hostname in a variable, and then only have to change the variable value
on deployment. Better, you could set the variable with a command line
argument, so you don't need to change any code on deployment, you just need
to change the command line arguments. Perhaps better, you could write code
that finds the hostname from the _current_ request, and uses that, so it
will transparently and automatically use the right one, regardless of what
host it's deployed on---assuming you want it to use the same hostname for
this static URL as is used to access the WO app itself.
Hope this helps,
--Jonathan
At 08:27 AM 9/16/2003 -0700, MadBrowser wrote:
Yeah, I should have included this info my original post...
The part of the JavaScript that pops up the window looks like this:
var obj_calwindow = window.open(
'calendar.html?datetime=' + this.dt_current.valueOf()+ '&id=' +
this.id,
'Calendar', 'width=200,height='+(this.time_comp ? 215 : 190)+
',status=no,resizable=no,top=200,left=200,dependent=yes,alwaysRaised=yes '
);
calendar.html is outside my WO app at /app/calendar.html. Now looking
at this again, it seems like perhaps the path is wrong and I'm getting
some kind of 404 in WO that wants a session... So...
I tried modifying the JavaScript source to change the path:
/calendar/calendar.html
to see if that would make a difference... Well, it does change
things... Now I get my Main component (a login screen) in my tiny pop
up.
Apparently this is because the HREF is still using the WO port (I'm in
dev mode in PB)... So I guess the solution is to specify a hard path in
the JavaScript like this: http://localhost/calendar/calendar.html? That
seems like a hack, since I'll have to change it before I deploy... Is
that my best option?
Thanks,
Hunter
On Tuesday, September 16, 2003, at 03:36 AM, email@hidden
wrote:
Hi Hunter
On Tuesday, September 16, 2003, at 07:44 am, MadBrowser wrote:
First off, thanks to everyone on this list. I'm obviously still
learning WO and you guys have been really helpful.
I am having a problem with a static A HREF in one of my Web
components... Basically this link looks like this:
<a href="javascript:cal1.popup();"><img src="/img/cal.gif" width="16"
height="16" border="0" alt="Click Here to Pick up the date"></a>
What URL does cal1.popup() load?
-- Denis.
_______________________________________________
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.