• 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: setting a browser window name in WebObjects
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setting a browser window name in WebObjects


  • Subject: Re: setting a browser window name in WebObjects
  • From: Denis Stanton <email@hidden>
  • Date: Fri, 8 Aug 2003 09:46:48 +1200

Hi Jonathan

Thanks for the advice. Your warning that browsers will alert if I use Javascript to close a window that wasn't opened by Javascript has saved me the time of trying that route. I have made it a policy to avoid javascript because of the variations. This particular client wants a couple of features that need javascript, but I want to keep it minimal. At least with a known client I can resolve compatibility issues by testing. Javascript was too much of a pain when I was writing websites for 23,000 students with a free choice of browsers

You could in fact just leave the first window open, with some simple message in it ("Thank you for using SuperWidgetPro, please see the main application window"), but open the second window, with your desired name and actual interactive content.

That's what I'm favouring at the moment. In fact my first window will be a login with a menu that only works if the login panel is validly completed (select from the menu without entering a valid name and it just returns the same screen). This window will open with <body onLoad = "window.name='main';">. All links from this page will have target=main.


On Safari the first window will not understand it's name so the links will open a second window called "main". The browser will then continue to use main except where I specify target="detail", and in this case I will always return from the detail window with target="main". The original login window will remain in the background. The hazard here is if they use the login screen again the browser will instantly bring the most recent "main" window to the front before going off to the server to get new data. Users will have to mistrust instant answers if Safari shows it is still loading.

On IE the first window will know it is named "main" so the subsequent target="main" will overwrite and the login screen will not be available. This is better.

I really like being able to say "of course it's better on Mac", so not recommending Safari is going to hurt!

Thank you for your help.

Denis



On Friday, August 8, 2003, at 03:33  AM, Jonathan Rochkind wrote:

Well, this is ugly, but rather than try to name the first window, you could change the definition of the problem: Have the first window immediately open a NEW window, with the name you desire and the appropriate starting content, and then immediately close the actual original window. You could just embed javascript in the first page to do this automatically when the page is loaded.

Unfortunately, since you didn't open the original first window yourself, when the javascript tries to close it, most browsers will give the user an alert, amounting to: "script is trying to close this window, do you want to close it?" You could in fact just leave the first window open, with some simple message in it ("Thank you for using SuperWidgetPro, please see the main application window"), but open the second window, with your desired name and actual interactive content.

It's ugly and messy, but the only way I can think of to arrive where you want on any browser (so long as it does javascript).

--Jonathan

At 09:22 PM 8/7/2003 +1200, Denis Stanton wrote:
Hi Chuck

Thank you. Nice answer, and it almost works. (well it really does work, but not on my browser of choice)

Unfortunately it would appear that Safari does not understand the window.name setting. In Safari a link with target="mainWindow" will use an existing window that has been named mainWindow by being opened by a previous link that specified target="mainWindow". If no such window exists it creates one. It does not seem to recognise an existing window that has been named with <body onLoad="window.name='mainWindow';>

Perversely (from my point of view) Internet Explorer on Mac does what I want. If I let WO open my first window with <body onLoad="window.name='mainWindow';">, a later link with < target="mainWindow" ... will go back to that window.

After using Safari for some time IE, once my favourite, seems so ugly.
I don't want to go back to it. Since my client is likely to be Windows-based I suppose it doesn't matter. Maybe I should file a request for Safari


Thanks for you help

Any other suggestion as to how I can name the first browser window in Safari would be welcome.

Denis

On Thursday, August 7, 2003, at 04:51  PM, Chuck Hill wrote:

At 01:40 PM 07/08/2003 +1200, Denis Stanton wrote:

Now my problem. How do I give the first browser window opened by my app a window name?
I've used this once before for a similar problem. To be honest, I don't
recall if it worked or not. There was a lot of other funky stuff going on.
Worth a quick try though...


Make the Body tag dynamic and add this binding:

onLoad = "window.name='mainwindow';"

A more nasty solution is to have the main window refresh every few seconds...


HTH

Chuck


--

Chuck Hill                                 email@hidden
Global Village Consulting Inc.
http://www.global-village.net

Denis Stanton
email@hidden
Home: (09) 533 0391
mobile: 021 1433622
_______________________________________________
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.


Denis Stanton
email@hidden
Home:  (09) 533 0391
mobile: 021 1433622
_______________________________________________
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.

  • Prev by Date: D2JC - JVM 1.4 on Windows client slow but fine on mac
  • Next by Date: Re: Backtracking - That Age Old Problem
  • Previous by thread: D2JC - JVM 1.4 on Windows client slow but fine on mac
  • Next by thread: select distinct error - model based fetch
  • Index(es):
    • Date
    • Thread