This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Webmaster forum > April 2006 > Q: app / doc cooperation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Q: app / doc cooperation
|
|
|
| I know it's silly to ask this here because folks will tell me to stop
doing wierd stuff, but I'll give it a shot anyway.
I have a web-app that runs in an access-controlled directory. Its
documentation runs in a public directory. I have links from the
web-app that will bring up the documentation in a new window. The
idea is that once it's brought up in the new window it can sit there
and be useful as the user works with the web-app.
Now, I also want to put links into the doc like "click here to do this
function" that will take the user back to the web-app. I have all of
this stuff working, *except* for one thing.
Once I've opened the doc in its new window, and the user clicks on a
"do this" link, I'd like that to come up in the original window. I've
tried target=_top and target=_parent in the links to the web-app but
it brings it up in the window where the doc was.
Is there some way to name the originating window where the web-app is
running so the doc can go back there? I'm not using framesets at
present.
Or to simplify the question, does anybody understand what I'm talking
about here?
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| Matt Probert 2006-04-26, 7:10 pm |
| On Wed, 26 Apr 2006 08:35:51 -0600, hug
<contact_info@sig_line.clickit> wrote:
>Or to simplify the question, does anybody understand what I'm talking
>about here?
I certainly don't!
But, that's nothing to be concerned about. We all sound like Pam Ayres
down 'ere <g>
Matt
--
Veritas Vincti
http://www.probertencyclopaedia.com
| |
| Mark Goodge 2006-04-26, 7:10 pm |
| On Wed, 26 Apr 2006 08:35:51 -0600, hug put finger to keyboard and
typed:
>I know it's silly to ask this here because folks will tell me to stop
>doing wierd stuff, but I'll give it a shot anyway.
>
>I have a web-app that runs in an access-controlled directory. Its
>documentation runs in a public directory. I have links from the
>web-app that will bring up the documentation in a new window. The
>idea is that once it's brought up in the new window it can sit there
>and be useful as the user works with the web-app.
>
>Now, I also want to put links into the doc like "click here to do this
>function" that will take the user back to the web-app. I have all of
>this stuff working, *except* for one thing.
>
>Once I've opened the doc in its new window, and the user clicks on a
>"do this" link, I'd like that to come up in the original window. I've
>tried target=_top and target=_parent in the links to the web-app but
>it brings it up in the window where the doc was.
>
>Is there some way to name the originating window where the web-app is
>running so the doc can go back there? I'm not using framesets at
>present.
>
>Or to simplify the question, does anybody understand what I'm talking
>about here?
I understand the question :-)
The short answer is that target=_parent only applies to framesets. To
get what you want, you have to give the original a name and then use
target=_name to refer back to it. But you can only do that by first
opening the app window from another page by means of a target=_name
link, so anyone who goes straight there via a bookmark won't see it
working properly.
You might be better off using javascript for this type of thing. If
you open the documentation window from the app window, then you can
refer back to the app window with window.opener.document. You'd need a
fallback for people who use the app with javascript disabled, but
that's no worse that what you've already got so there's nothing to
lose, in this situation, by scripting it.
Mark
--
Blog: http://mark.goodge.co.uk Photos: http://www.goodge.co.uk
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!
| |
|
| Mark Goodge <usenet@listmail.good-stuff.co.uk> wrote:
>I understand the question :-)
Thank gunness!
>The short answer is that target=_parent only applies to framesets. To
>get what you want, you have to give the original a name and then use
>target=_name to refer back to it. But you can only do that by first
>opening the app window from another page by means of a target=_name
>link, so anyone who goes straight there via a bookmark won't see it
>working properly.
I'll have to check into framesets I reckon. The user will have to log
in under any circumstances, so there is already a link (well, a form
button) it's a matter of changing it. I avoid frames like the plague
because I consider them search-engine hostile and browser-find
hostile, but this is a special case not the general site. Thanks
Mark.
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| Ben Jamieson 2006-04-26, 10:53 pm |
| On 2006-04-26 15:29:56 -0400, hug <contact_info@sig_line.clickit> said:
> Mark Goodge <usenet@listmail.good-stuff.co.uk> wrote:
>
>
> Thank gunness!
>
>
> I'll have to check into framesets I reckon. The user will have to log
> in under any circumstances, so there is already a link (well, a form
> button) it's a matter of changing it. I avoid frames like the plague
> because I consider them search-engine hostile and browser-find
> hostile, but this is a special case not the general site. Thanks
> Mark.
the Javascript option would probably be better.
Yes, there is a percentage of folks who don't have javascript enabled,
but its a far more sophisticated way to do it than framesets.
Also, with more an more web apps being written that employ heavy
javascript usage, many are realising that javascript is actually a
valuable and powerful addition to a website. The number of folk who
disable it is slowly shrinking (or they are in my stats for around 100
sites over the past two years).
There are legitimate reasons why a very small percentage of users may
disable javascript, so you need to balace your target market with this
consideration and decide from there.
There will, of course, always be a percentage of people who simply say,
no, javascript is a bad thing - its dangerous and ermmm bad, I'll never
enable it. Ever. Its bad!
They probably also drive steam powered cars, refusing to accept these
new fangled gasoline powered things....
Just my Ha'penny's worth.
| |
|
| Mark Goodge <usenet@listmail.good-stuff.co.uk> wrote:
>On Wed, 26 Apr 2006 08:35:51 -0600, hug put finger to keyboard and
>typed:
>
>
>I understand the question :-)
>
>The short answer is that target=_parent only applies to framesets. To
>get what you want, you have to give the original a name and then use
>target=_name to refer back to it. But you can only do that by first
>opening the app window from another page by means of a target=_name
>link, so anyone who goes straight there via a bookmark won't see it
>working properly.
>
>You might be better off using javascript for this type of thing. If
>you open the documentation window from the app window, then you can
>refer back to the app window with window.opener.document. You'd need a
>fallback for people who use the app with javascript disabled, but
>that's no worse that what you've already got so there's nothing to
>lose, in this situation, by scripting it.
>
>Mark
Huh. I'm not having much luck with this. Forget javascript, that
ain't going to happen.
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| mbstevens 2006-04-27, 3:52 am |
| Ben Jamieson wrote:
> They probably also drive steam powered cars,
More likely electric/gas hybrids while surfing with a phone
or handheld. WML allows scripts, HDML does not. Opera for mobile PC has it.
There are good uses for javascript, but using it as a replacement
for frames is not a good one. Either preprocessing or server side
scripting should be used for that. Also, anything in javascript
that is necessary to the page but can't be covered by <noscript>
redundancy is suspect. I don't really understand the resistance
to server side scripting that I often see -- it is really no harder
than learning javascript and more reliable across visitors' browsers.
--
mbstevens
http://www.mbstevens.com/
| |
|
| NNTP-Posting-Host: p-852.newsdawg.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Newsreader: Forte Agent 1.8/32.553
Xref: number1.nntp.dca.giganews.com alt.www.webmaster:484654
mbstevens <NOXwebmasterx@xmbstevensx.com> wrote:
>I don't really understand the resistance
>to server side scripting that I often see -- it is really no harder
>than learning javascript and more reliable across visitors' browsers.
What folks are comfortable with always seems somehow safer and better
than anything else. Not necessarily a bad thing I guess. I got a
case of that myself maybe, I'm not about to put a minute into learning
javascript for the privilege of introducing more possibilities for
conflicting end-user settings into an already-sloppy client/server
system.
You wouldn't have any idea how I can get this thing working across two
browser windows would ya?
I'm starting to think perhaps it would be better just to run it all in
a single window. The user can use the browser's backspace button to
go back to the app or back to the doc, the server-side doesn't lose
track of what it was doing. The guy can always print of a full copy
of the doc and have the paper copy on his desk.
The real problem I'm seeing with this whole approach amounts to the
fact that the app is fetching up chunks of the doc to give
explanations along with inputs and suchlike. The server isn't real
fast, and once people actually start using it (if they ever do) I'll
probably need a dedicated server to keep partway up with it. As it
is, opening the doc in a second window was thunk of as a convenience
for the user so drinking coffee while it fetches up the doc one more
time wouldn't be necessary.
I've seen the page generation time on my server vary as much as almost
10 seconds from one request to the next (for the same thing) depending
what else is going on with the shared server. It would be real nice
to have a dedicated server just to get a better handle on what the
heck is going on. Alas money is the showstopper on that one, as
usual.
But, I got this idea the other day, and I really like it. The idea of
the doc being able to cooperate with a web-app seems pretty cool to
me. The guy opens up the site configuration tool running on his
server, pulls up the doc on my server, clicks on a "do this" link in
the doc, and it brings up that function within the site configuration
program running on his server. It could make for a very cool tutorial
or assisted configuration setup.
Maybe I need to run it all in a single browser window, and make it
clear in the doc that unless you have a fast connection and my server
is in a good mood, you should just print and memorize the doc instead
of using the doc-assisted functionality. I dunno, sometimes I feel
like a real dunce.
Ideas would be most welcome.
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| mbstevens 2006-04-27, 10:57 pm |
| hug wrote:
> I'm starting to think perhaps it would be better just to run it all in
> a single window. The user can use the browser's backspace button to
> go back to the app or back to the doc, the server-side doesn't lose
> track of what it was doing. The guy can always print of a full copy
> of the doc and have the paper copy on his desk.
>
> The real problem I'm seeing with this whole approach amounts to the
> fact that the app is fetching up chunks of the doc to give
> explanations along with inputs and suchlike. The server isn't real
> fast, and once people actually start using it (if they ever do) I'll
> probably need a dedicated server to keep partway up with it. As it
> is, opening the doc in a second window was thunk of as a convenience
> for the user so drinking coffee while it fetches up the doc one more
> time wouldn't be necessary.
>
> I've seen the page generation time on my server vary as much as almost
> 10 seconds from one request to the next (for the same thing) depending
> what else is going on with the shared server. It would be real nice
> to have a dedicated server just to get a better handle on what the
> heck is going on. Alas money is the showstopper on that one, as
> usual.
Perhaps your caching on your client is turned off or you're opening
the pages in the same window instead of tabs? That kind of stuff is
up to the visitor. If they want to use their browser in a way that
slows them down, we shouldn't interfere.
>
> But, I got this idea the other day, and I really like it. The idea of
> the doc being able to cooperate with a web-app seems pretty cool to
> me. The guy opens up the site configuration tool running on his
> server, pulls up the doc on my server,
....I'm confused here. You're both running servers...?...
> clicks on a "do this" link in
> the doc, and it brings up that function within the site configuration
> program running on his server.
You have basically described one of the
abilities of javascript as client to process requests
within a web page, which is a very limited system
over the net because of security that had
to be built into javascript. Microsoft's Active
X functionality is more powerful and full of security
holes. I keep it turned off when using Windows based
machines.
Your explanation in your last paragraph wasn't very clear
to me, but you should also have a look at Soap and XML-RPC
-- these can convert a function call on a client to a function call
on a remote machine using XML to describe this request.
> It could make for a very cool tutorial
> or assisted configuration setup.
>
> Maybe I need to run it all in a single browser window, and make it
> clear in the doc that unless you have a fast connection and my server
> is in a good mood, you should just print and memorize the doc instead
> of using the doc-assisted functionality.
You could advise them to use tabbed browsing if they want to, or to
open the pages in new windows if they want to. Or advise them
that their experience might go faster if their browser- caching is
turned on. Just don't force them to do so.
| |
|
| mbstevens <NOXwebmasterx@xmbstevensx.com> wrote:
>hug wrote:
>
>
>Perhaps your caching on your client is turned off or you're opening
>the pages in the same window instead of tabs? That kind of stuff is
>up to the visitor. If they want to use their browser in a way that
>slows them down, we shouldn't interfere.
>
>
>...I'm confused here. You're both running servers...?...
>
>
>You have basically described one of the
>abilities of javascript as client to process requests
>within a web page, which is a very limited system
>over the net because of security that had
>to be built into javascript. Microsoft's Active
>X functionality is more powerful and full of security
>holes. I keep it turned off when using Windows based
>machines.
>
>Your explanation in your last paragraph wasn't very clear
>to me, but you should also have a look at Soap and XML-RPC
>-- these can convert a function call on a client to a function call
>on a remote machine using XML to describe this request.
>
>
>You could advise them to use tabbed browsing if they want to, or to
>open the pages in new windows if they want to. Or advise them
>that their experience might go faster if their browser- caching is
>turned on. Just don't force them to do so.
I've decided to run it all in one window, and all on one server.
While running the doc off my server lets me keep it updated, it's much
more important that the version of the doc the guy is using match the
version of the code he's using. Thanks.
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| Ben Jamieson 2006-04-27, 10:57 pm |
| MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Unison/1.7.5
X-Complaints-To: abuse@supernews.com
Lines: 10
Xref: number1.nntp.dca.giganews.com alt.www.webmaster:484685
On 2006-04-26 23:35:56 -0400, mbstevens <NOXwebmasterx@xmbstevensx.com> said:
> More likely electric/gas hybrids while surfing with a phone
> or handheld. WML allows scripts, HDML does not. Opera for mobile PC has it.
How'd you figure that? They resist technology that has clear
advantages, but drive the latest cars?
Bizarre!
| |
|
| Ben Jamieson <ben@thymeonline.com> wrote:
>On 2006-04-26 23:35:56 -0400, mbstevens <NOXwebmasterx@xmbstevensx.com> said:
>
>
>How'd you figure that? They resist technology that has clear
>advantages, but drive the latest cars?
>
>Bizarre!
Some technology has clear advantages AND clear disadvantages.
Hybrid cars might have the advantages without the disadvantages, I
really don't know what the automotive world has been up to lately.
All client-side scripting has some clear disadvantages, such as the
ability of the user to control scripting via browser settings.
Most technology involves some kind of tradeoff. Mileage varies.
--
http://www.ren-prod-inc.com/hug_sof...?action=contact
| |
| Ben Jamieson 2006-04-27, 10:57 pm |
| On 2006-04-27 09:36:12 -0400, hug <contact_info@sig_line.clickit> said:
> Some technology has clear advantages AND clear disadvantages.
>
> Hybrid cars might have the advantages without the disadvantages, I
> really don't know what the automotive world has been up to lately.
>
> All client-side scripting has some clear disadvantages, such as the
> ability of the user to control scripting via browser settings.
>
> Most technology involves some kind of tradeoff. Mileage varies.
I was talking about the type of user that disables it beacuse it is
'bad', regardless of the benefits, of which there are many.
Nothing to do with the technology itself.
Anyways, enough of this. Back to the topic
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|