Re: History Replacement And New Location Combined


"abc" <vpozek@xxxxxxx> wrote in message
news:1184170273.399562.105370@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"David Mark" <d...@xxxxxxxxxxx> wrote in his message
<469489c7$0$30643$4c368faf@xxxxxxxxxxxxxx>

Not sure what you mean by "synchronize", but I think the location.replace
will stop your script dead in its tracks.

In his book "JavaScript - The Definitive Guide", David Flanagan gives
on page 248 an example of History and Location objects usage. He has a
form with 'back' and 'forward' buttons serviced by accompanying JS
functions. Here's just one of them:

<script>

// The function is invoked by the Back button in our navigation bar

function go_back(){

// First, clear the URL entry field in our form.
document.navbar.url.value = "";

// Then use the History object of the main frame to go back.
parent.frames[0].history.back();

// Wait a second, and then update the URL entry field in the form
// from the location.href property of the main frame. The wait
seems
// to be necessary to allow the location.href property to GET IN
SYNC.

Okay, he wants to let the browser catch up before setting the location.href.
As counter-intuitive as it might sound, he could probably have used a
timeout of 0.

setTimeout("document.navbar.url.value =
parent.frames[0].location.href;", 1000);
}

It seems that you are right about location.replace() stopping my
script: I've tried different gymnastics without any success.

Yeah. It does just what it says.


I have to admit, I can't figure out what you are trying to accomplish
here.

Just by asking your question "What are you trying to accomplish here?"
you helped me clear out my confusion! Now I realize that I do not need
coupled bookmarking and next page loading, and why they are aparently
mutually exclusive in JavaScript.

Glad to help.


But I can tell you that you don't want a form with a javascript action.

I owe you a short application description here. It's about meat
cutting decision making tool for retail industry. Since I don't know
what decisions user might make (how many meat cuts out of the initial
primal, at what price, with what trimmings, etc.), I need a full
flexibility and independence on the client side (browser), which
assumes unloading the burden off the MySQL server and saving the
database into the web pages as a set of JS Array objects (delivered as
Server Side Includes). In such a context, I need JS for servicing
user's requests.

You can do all of that, but you should look into the onsubmit event of the
form object. The way you are doing it is bad form (no pun intended.)


The meat cutting process happens through a set of pages containing
spreadsheets generated by JS and DOM. Since my client is a spoiled
one, he needs on top of it the possibility of leaving the process at
any point and continuing it later on. But, then again, since
bookmarking remembers only the URL used to invoke a page, I have to
provide functionality which would on the bookmark request remember the
current values of the spread*** in the current page, and substitute
the newly constructed URL for the initial one in the location bar.

I hope i didn't misunderstand your remark.

I get it now. Sort of. Did you consider a cookie-based solution to persist
the data?


Can you post a link to a page that works without JS and how
you are trying to enhance the experience with JS?

Unfortunately - no, there are no pages w/o JS! On the contrary,
they're all JS intensive. You cannot reach the pages since they're
hosted by our password protected development server but, if you are
still interrested, I would be more than happy to send you the URL once
the application's posted on our production server.

Sure. I am curious to see this thing. If this is going to be a public app
(eg on the Internet), it must not use the javascript: syntax in your form
action. Hint: the action should be an error page that explains to the user
that the application requires scripting. Alternatively, you can create the
form with script and put a similar message in a NOSCRIPT tag. In that case,
your onsubmit handler would always return false and the server won't be hit
at all.


Thank you very much indeed, David, for your pertinent questions and
please accept my apologies for my asking for help prematurely.

No problem. Not sure what that means, but it is better than asking for help
when it is too late!


.

Loading