Dynamic Query String Variables?

[julie.siebel]

I'm working on a rather complex booking system for building European
trips, in a combination of SQL/VBScript/Javascript. There are tons of
query string variables that get passed back and forth between the
pages, and in almost every case, I can set 'em up fine, provided the
variables are in the link.

The page the *holds* the booking information, though, is problematic.

An example trip might include two European cities or towns with a week
in each in an apartment or cottage that the user selects from a dozen
or properties for each region.

All the information is on one page (all the dozen or so properties for
each weeks, available dates for the trip and for each , max occupancy
per property, pricing per property and per number of passengers,
etc...everything necessary to actually book the trip). If the user
changes party size or chooses a date, properties are hidden or shown
depending on max occupancy and/or availability.

So, a user sets their date and party size (or maybe just the party
size, or maybe has just cleared everything out to start over...) then
wants to view available properties so they can find one they like. The
current pax/date/etc. information is not in the query variables,
because the link was built at runtime.

If I build the link in an onclick event, it breaks if someone right
clicks to open a new page or tab.

I hate sites that disable right click menu. I hate sites where, when
you open a new page with a right click, it generates a javascript
error if the URL is created with an onclick event. I hate that using
an onclick to bring up the page means whatever is showing in the
status bar bears no resemblance to the page that is brought up when
you click on the link.

My client isn't worried about the non-javascript people for this use;
those people are referred to a free spiffy catalog, which frankly, is
how most of this client's customers book their trip anyway. I just
want to be able to carry the variables in such a way as to not break
the site if someone right clicks.

Anybody have any suggestions? Is it hopeless?

Thanks,

Julie

 

[Thomas 'PointedEars' Lahn]

So, a user sets their date and party size (or maybe just the party
size, or maybe has just cleared everything out to start over...) then
wants to view available properties so they can find one they like. The
current pax/date/etc. information is not in the query variables,
because the link was built at runtime.

That's a design error which causes your problem. You can easily build
the link to contain your client-side variables, then.

If I build the link in an onclick event, it breaks if someone right
clicks to open a new page or tab.

I hate sites that disable right click menu.

Don't do that, then.

I hate sites where, when you open a new page with a right click, it
generates a javascript error if the URL is created with an onclick
event.

Those sites are badly designed, too.

I hate that using an onclick to bring up the page means whatever is
showing in the status bar bears no resemblance to the page that is
brought up when you click on the link.

If there even is a status bar.

My client isn't worried about the non-javascript people for this use;
those people are referred to a free spiffy catalog, which frankly, is
how most of this client's customers book their trip anyway. I just
want to be able to carry the variables in such a way as to not break
the site if someone right clicks.

Or left-clicks. There are left-handed people, you know.
Or Compose/Menu key presses. There are keyboards.
Or ...

Anybody have any suggestions? Is it hopeless?

No, you can use an accessible link that is only enhanced with script:

<a href="..." onclick="whatever(); return false;">...</a>

Which is what you should have done in the first place.


HTH

PointedEars

 

[julie.siebel]

That's a design error which causes your problem. You can easily build
the link to contain your client-side variables, then.

This is the design the the client wants.

No, you can use an accessible link that is only enhanced with script:

<a href="..." onclick="whatever(); return false;">...</a>

Which is what you should have done in the first place.

This is what I have now, that's the problem. If a user right clicks to
open a new page, they will get the page in the HREF tag, which does
not reflect the change they made in their booking, because the onclick
event doesn't fire.

Disabling the right click would fix the problem, but I won't do that,
nor will I turn the link into a javascript: void or whatever that is.

I could turn the link button into a form submit button, so they can't
override it with a right click, but that is not good use of the Form
command, and the page is already pretty complex.

I could just make the links go to a page that says "Please don't use
right click, because we can't track your selected date and party size"
and that is probably what I do if all else fails...but then the status
bar (for those who have one, and watch such things - I have, and I do)
will read something like "dontrightclick.html" - lol - which is not
great either.

Since I can't add query variables dynamically to the href URL, I think
I'm going to try wrap the link in a div and use inner.html and try
rewriting the entire DIV when the date or party size changes. It's the
only way I can think of to update the URL. Might work...if not, I
guess they are stuck with a page explaining why they can't do this.

Thanks,

Julie

 

[Thomas 'PointedEars' Lahn]

This is the design the the client wants.

I doubt that the client set any conditions about the structure of the link.
What they want is only the functionality.

This is what I have now, that's the problem. If a user right clicks to
open a new page, they will get the page in the HREF tag,

Attribute, not tag.

which does not reflect the change they made in their booking, because
the onclick event doesn't fire.

So you modify the link accordingly. I don't see the problem.

[...]
Since I can't add query variables dynamically to the href URL, [...]

Yes, you can:

referenceToHTMLAnchorElement.href = "foo";


PointedEars

 

[julie.siebel]

I doubt that the client set any conditions about the structure of the link.
What they want is only the functionality.

I thought by design error you meant the design of the page - the
everything-and-the-kitchen-sink-on-the-darn-page-ness of it. Sorry.

So you modify the link accordingly. I don't see the problem.

How do I modify the HREF to add the dynamic query variables? That's
what I was asking in the original post, I just did it badly.

[...]
Since I can't add query variables dynamically to the href URL, [...]

Yes, you can:

referenceToHTMLAnchorElement.href = "foo";

So...I'm not understanding this - give the anchor an ID use that in
the JS routine that is called when they switch party size or date,
or...? It can't do it in the onclick routine for the link, because
onclick won't fire if they right click and open in a new window.

It sounds as though this what I'm looking for, but I don't understand
what you are telling me to do.

Julie

 

[julie.siebel]

That's a design error which causes your problem. You can easily

I'm not sure I'm totally following you, but perhaps this is a great
situation for using AJAX - don't load all the information at runtime, load
them into the page (hidden form fields?) as selections are made by the
user.

ie: user chooses a date, AJAX hits the database to pull up properties
available on that date. They change the date? The same AJAX call gets the
appropriate info. Same thing for party-size, etc...

You are absolutely correct, this absolutely *should* have been done in
something like AJAX. 20/20 hindsight. Unfortunately, this mess has to
be up and running early next week - once it's up, I may go back and
learn AJAX and rewrite it, but for now, I am stuck.

Julie

 

[Thomas 'PointedEars' Lahn]

How do I modify the HREF to add the dynamic query variables? That's
what I was asking in the original post, I just did it badly.

I'm still not clear what you mean by "dynamic query variables".

Are you looking for window.location.search?

[...]
Since I can't add query variables dynamically to the href URL, [...]

Yes, you can:

referenceToHTMLAnchorElement.href = "foo";

So...I'm not understanding this - give the anchor an ID use that in
the JS routine that is called when they switch party size or date,
or...?

Exactly. But an ID may not be needed.

It can't do it in the onclick routine for the link, because
onclick won't fire if they right click and open in a new window.

Of course you can't.

It sounds as though this what I'm looking for, but I don't understand
what you are telling me to do.

Unfortunately, I'm still not sure I understand how your site works.

Maybe you could you post the URL of a test case?


PointedEars

 

[julie.siebel]

I'm still not clear what you mean by "dynamic query variables".

Are you looking for window.location.search?

Unfortunately, I'm still not sure I understand how your site works.

Maybe you could you post the URL of a test case?

Well, the page is (obviously) broken at the moment...I'm not even sure
which version of the problematic links are up - lol - but I'll post it
at the end of this. It might not be necesary, though, if I could just
explain a little better. I seem to be having a real problem with that
today!

When the page loaded, each page has a button that, in a perfect world,
would have an ordinary href with query string variables. Sometimes
there will be no date or no Pax (party size) - it depends where they
are at in the process. Sometimes there will be a LOT of information,
as we need to store their choices as they move from page to page.

So, a simplified version of the link might be.

<a href="prop.asp?sid=9999&date=18Jun2008&slot2=8888&pax=2"><img
src="viewpropertybutton.gif" border="1"></a>

Now if they change the party size or the date, a series of javascript
function hides the properties that don't fit the criteria. So let's
say, that before viewing properties, they change pax to 4 people and
date to 25 Jun 2008. The link, then, needs to change to

<a href="prop.asp?sid=9999&date=25Jun2008&slot2=8888&pax=4"><img
src="viewpropertybutton.gif" border="1"></a>

....so that when they come back from the property page, all of there
information is still in place, and they are only looking at 4 person
properties.

Since functions ARE executed when the party size or date changes, if
there was a way to access the link, I could change them then. I just
haven't figured out how to access the link.

If that doesn't give enough information about what I'm trying to do,
here's my broken dev page. Pardon the messiness of it if you look at
the coding - a chunk of the page is generated, rather than written.

http://www.idylladmin.com/dev/public/website/sampler.asp?RID1=331&RID2=323&Code=08STVE

What I'm talking about is, if you click a property name or picture,
information about the property is shown (a brief description) with a
button so they can view detailed information about the property.
That's the button that I'm having problems with.

(Note that I think the actual property pages are disconnected on this
version, and if not, they probably hook up to a property page that's
broken - the whole thing is in flux at the moment. Won't finish the
prop pages until I solve this link problem, so I know what I am
dealing with.)

Thanks for any insight.

Julie
(Who cannot WAIT until these pages are done.)

 

[Thomas 'PointedEars' Lahn]

[...]
If that doesn't give enough information about what I'm trying to do,
here's my broken dev page. Pardon the messiness of it if you look at
the coding - a chunk of the page is generated, rather than written.

http://www.idylladmin.com/dev/public/website/sampler.asp?RID1=331&RID2=323&Code=08STVE

What I'm talking about is, if you click a property name or picture,
information about the property is shown (a brief description) with a
button so they can view detailed information about the property.
That's the button that I'm having problems with.

As you have ASP available, you can use that to generate a new version of the
document that contains information e.g. about the selected date. Because if
client-side scripting is not available, you could generate that link with
ASP, too, in the following fashion:

<script type="text/javascript">
function pickDate(sDate, ...)
{
// ...
return false;
}
</script>

<a href="?date=2008-04-23" onclick="return pickDate('2008-04-23', 1);"

23 Apr 2008</a>

Then you could rewrite the current

<div class="prophead">
<a href="jsrequired.html" onclick="showdesc(3135);return false;"><img
class="tns" id="tn3135"
src="http://www.idylladmin.com/3/3135_3135-03-m-11-04-05.jpg" border="0"
height="85" width="125"></a>
<div id="n3135"><a href="jsrequired.html" onclick="showdesc(3135);return
false;">Collina #36</a></div>
<div id="v3135">Locarno</div></div>
<b>Sleeps 2</b><br>
<div class="propdesc" id="a3135">&nbsp;</div><br clear="right">
<div style="visibility: visible; display: block;" id="d3135"
class="propdescblock">
<table><tbody><tr><td valign="top">The Collina #36 vacation rental is a
fine accommodation in a very practical location. The modern apartment
features a furnished balcony with a dramatic view overlooking Locarno and
the high mountains.</td><td valign="top">
<a href="prop.asp?sid=3135"><img src="images/spropdetails.gif"
border="0"></a><br>
<a href="jsrequired.html"><img id="c3135" onclick="pickprop(3135,1);return
false;" src="images/schoosepropdate.gif" border="0" vspace="3"></a>

as follows:

<div class="prophead">
<a href="showdesc.asp?3135" onclick="showdesc(3135); return false;"><img
class="tns" id="tn3135"
src="http://www.idylladmin.com/3/3135_3135-03-m-11-04-05.jpg" border="0"
height="85" width="125"></a>
<div id="n3135"><a href="showdesc.asp?3135" onclick="showdesc(3135);
return false;">Collina #36</a></div>
<div id="v3135">Locarno</div>
</div>

<b>Sleeps 2</b><br>
<div class="propdesc" id="a3135">&nbsp;</div><br clear="right">
<div style="visibility: visible; display: block;" id="d3135"
class="propdescblock">
<table>
<tbody>
<tr>
<td valign="top">The Collina #36 vacation rental is a fine
accommodation in a very practical location. The modern apartment features a
furnished balcony with a dramatic view overlooking Locarno and the high
mountains.</td>
<td valign="top"><a href="prop.asp?sid=3135"><img
src="images/spropdetails.gif" border="0"></a><br>
<img id="c3135" onclick="pickprop(3135, 1);return false;"
src="images/schoosepropdate.gif" border="0" vspace="3">


It would be even more user-friendly if you hid the details section only if
client-side scripting was available (you can do this for all items with
`<body onload="hideAllDetails()">' and the like).

You should apply http://validator.w3.org/ on your generated markup first.


PointedEars

 

[julie.siebel]

As you have ASP available, you can use that to generate a new version of the

document that contains information e.g. about the selected date.

Oh, Thomas - I wish I could. The SQL that generates all of that data
for the page is about 10k (they run about 80 of these various trips,
in 10 countries and 24 regions, with 400 properties, price changes
depending on the date, price changes depending on the party size,
price changes depending on the property (and the party size AND the
date), and not all party sizes are available for all trips!) The SQL
is way efficient (runs in 2/10 second, even under load) but the server
hit would just be enormous, as people click a date to see what
properties are available on THAT date, then click another date, etc.

Should have stopped, learned AJAX, and did it that way, but - 20/20
hindsight.

It would be even more user-friendly if you hid the details section only if
client-side scripting was available (you can do this for all items with
`<body onload="hideAllDetails()">' and the like).

Again, I wish I could - the javascript (because I can't use a reload
as described above) is what shows the client the price of their trip
and stuff, and makes the booking button available once they have set
all of their options...plus there are parts of the site that I
inherited from that aren't being rewritten, that won't work without
javascript, so a js free version isn't an option, and hasn't been
since the this version of the site was launched 3-4 years ago.

Ah, well - it'll all work, provided I let those right-clickers know
they need use the left mouse button. I was just hoping for a client-
side solution to change those links.

You should applyhttp://validator.w3.org/on your generated markup first.

OMG yes - lol - it's a mess, isn't it? It'll validate before it's
posted to the live site, and possibly before, if I have strange
problems with stuff that I *know* should work. Right now, I'm changing/
reuploading this file every 15 minutes or so, so I can't stop to
validate to run the resulting code through validation every time, or
the job would never get done.

I've solved lots of supposed "javascript problems", "css problems" and
"html problems" by running things through a validator.

Thanks for your help, anyway.

Julie

 

[julie.siebel]

Currently, in my page, all of the links in question can be associated
with a supplier number. There is an array of these supplier numbers,
which is run through a "for" loop for various other purposes. If I
either named or ID'd all my links with like name="h9999" or
ID="h9999", where 9999 is the supplier number...

Would something like this work for replacing the URL string with query
string variables in these links? Whenever the passengers changes or
the date changes, do the following:

function changeURL() {
var URLString = "whatever" //build the URL string here.
for (i=0;i<Supplierlist.length;i++) {
document.links["h" + Supplierlist].href = URLstring;
}

Are there compatibility issues with this, other than the fact that
javascript is required?

And if it'll work, should I name= 'em or ID= 'em?

Thanks,

Julie

P.S. At the very least, if it's workable, I'd like to know what the
compatibility hit would be. Thx. J.

 

[julie.siebel]

Except with the syntax correct, of course - lol - corrected, below, I
*think*:

function changeURL() {
var URLString = "whatever" //build the URL string here.
for (i=0;i<Supplierlist.length;i++) {
document.links["h" + Supplierlist].href = URLString;
}
}

(Sheesh, what an idiot.)

 

[julie.siebel]

To other people searching for answers to this problem, this seems to
work, though I'm not sure about compatibility at this point:

In this (mycase) Supplier list is an array that holds the numbers
assigned to the links I was trying to change - not consecutive
numbers, just ID numbers for a particular type of data.

function changeURL() {
var URLString = "whatever" //build the URL string here.
for (i=0;i<Supplierlist.length;i++) {
document.links["h" + Supplierlist].href = URLString;
}

}

A few of the things I searched for when trying to find it included the
word javascript then (with or without quotes, but mostly with), so
that this comes up if someone is looking for something similar:
change a URL, rewrite a URL, change a link, rewrite a link, change an
href, redefine an href, rewrite an href, dynamic links, dynamic query
strings, dynamic query variables. Sometimes these same phrases with
"right click" "onclick event", because I was looking for a
substitution for onclick when right clicking.

Apparently, you can also attach an event to the right-click
contextmenu (document.oncontextmenu, according to www.quirksmode.org)
without actually breaking the context menu, but it looked pretty
buggy.

If I determine compatibility is a problem, I will post back.

Julie

 

[pr]

To other people searching for answers to this problem, this seems to
work, though I'm not sure about compatibility at this point:

In this (mycase) Supplier list is an array that holds the numbers
assigned to the links I was trying to change - not consecutive
numbers, just ID numbers for a particular type of data.

function changeURL() {
var URLString = "whatever" //build the URL string here.
for (i=0;i<Supplierlist.length;i++) {
document.links["h" + Supplierlist].href = URLString;
}

}

[...]

Not in IE6 (at least), which on this rare occasion insists on using a
W3C approved method: document.links.namedItem(), making your function
something like this:

function changeURL() {
var URLString = "whatever";
var dl = document.links;

if (dl.length > 0) {
var isDOM1 = (typeof(dl.namedItem) != "undefined");

for (var i = 0; i < Supplierlist.length; i++) {
if (isDOM1) {
dl.namedItem("h" + Supplierlist).href = URLString;
} else {
dl["h" + Supplierlist].href = URLString;
}
}
}
}

You'll find recent versions of Firefox, Opera and Konqueror also use the
DOM 1 method, if available, although you should retain both methods if
you want to support antique browsers.

See http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html.

 

[julie.siebel]

so I'm wondering why you chose not to use cookies .. yes, they are not
ubiquitous, just like JS can not be, because the user can deny them or
turn them off, but stashing the QUERY_STRING into a cookie and reusing
it certainly sounds like an option at the least.

These guys have another, property-only site, that the coder initially
built using cookies, that caused nothing but problems, so they are
cookie shy. I had to go back and convert all the cookie reads and
writes to query variables. I think it had something to do with people
viewing multiple property windows before selecting, or something -
things got out of sync, plus there were indeed some folks who didn't
accept even session cookies.

It would sure make for a prettier URL - in some of these trips, the
query string is 12 characters long.

The thing I'm worried about with rewriting the URL the way I am is
persistence when someone hits the back button, but we'll see how it
goes. Hmmm...maybe use the cookie as a backup?

I'm just going to cobble the thing together at this point so it's
ready on Monday, then go back and see how I can make it work better.
"Good Man" was right - this really should have been done in AJAX.

Julie

 

[Thomas 'PointedEars' Lahn]

"Good Man" was right
No.

- this really should have been done in AJAX.

Thereby excluding even more customers.


PointedEars

 

[Richard Cornford]

Yeah, I guess there are a ton of people browsing the
web without a client that can handle AJAX... not.

At the turn of the century web browsers on mobile phones where crude or
non-existent. These days it is difficult to get a mobile phone that does
not have a web browser built into it. Presumably this trend either
reflects an increase in demand for browsing with such devices, or will
result in one. So what proportion of such embedded browser cannot handle
AJAX (given the relatively slow processors arable and the very
restricted memory on such devices, plus the cost of connections).

But IE 6 is still the most popular browser in use, and it only supports
AJAX if it is configured to do so, and that configuration can reasonably
be argued to be an unwise configuration in the Internet security zone.
That is, you have to have the scripting of ActiveX components that are
"marked safe for scripting" enabled. As historically ActiveX had been
IE's security Achilles heal and an ActiveX object being "marked safe for
scripting" had never been the same as its being safe for scripting it is
a reasonable security measure to completely disable Active X in the
Internet security zone (and only enable the 'safe' form in the trusted
zone).

AJAX is a great technology for web applications, and can be viable and
useful on Intranets (where in both cases the user (or their
administrators) can make an informed decision about putting the URL in
the 'trusted zone'), but for public access information services and
(particularly) e-commerce it may be a less obvious form of shooting
yourself (or your emplyer) in the foot.

Hey, let's program like it's 2003!

You say that like there was something wrong with 2003. In retrospect
2003 may prove one of the most influential years in history of
client-side scripting. It witnessed the start of the popularisation of
the serious interest in the exploitation of closures in javascript that
has now permeated pretty much all serious javascript authoring, and the
invention and development of what is apparently now to be called
"Crockford's Module Pattern".

Richard.

 

[Richard Cornford]

^^^^^^
Should have been "available".

I appreciate your comments!

I'm not sure I understand what you are saying here, but I think
you're saying that (most) mobile devices presumably don't have AJAX
capabilities at the moment.

I don't know what "most mobile devices" are capable of at all. But there
are good reasons to expect them to have inconsistent support for some of
the more advanced features of desktop browsers.

I agree, and I think we all agree that
mobile browsing is still in the early stage.

That would be very relative. Javascript started in the middle of the
last decade of the 20th century. Scriptable mobile browsers existed by
the turn of the century.

You can bet that as mobile browsers take off, the userbase
will DEMAND that the browsers are able to visit their
favorite "2.0"-style websites: Flickr, Digg, Facebook,
etc. and be fully functional.

But whom will they demand that off? Is the fault with the web site or
the browser? Won't the users see some sites as fully functional on their
mobile browsers and so see the non-functional sites as the
responsibility of the web sites and not the browsers.

But you are correct, I assume anyone trying to book flights
on a cellphone for this particular application would be SOL.

Not necessarily. There is no technical reason why flights could not be
booked using a (any) browser that supports only HTTP and HTML, and such
support is about the minimum that is necessary for any software to
qualify as a web browser.

But how many people are really booking flights via
cellphone?

Who could say?

And surely the people savvy enough to try realize that the
mobile browsers right now just can't handle it properly and
they'd be better off doing it in office/at home.

Mobile browsers are quite capable of facilitating it right now. If you
cannot book flights with a mobile web browser it was a positive action
on the part of a web developer that prevented it.

Really? Either I've done this on my browser (and don't
recall doing so), or I'm misunderstanding?

Misunderstanding apparently.

Are you saying that javascript is
disabled by default?

I am not talking about javascript at all. I am talking about the ability
of scripts to instantiate and interact with ActiveX objects (and
particularly the subset of such objects "marked safe for scripting",
which includes the XML HTTP request object necessary for AJAX).

If so a simple <noscript> can alert the users?

Alert the users to what exactly? It does not seem to dawn on many web
site authors that telling the average member of the public that
"javascript is required" is about as pointless as telling them that
"Epimenidies was wrong". It is a general failure on the part of
individuals who have a reason to know what javascript is (more or less)
to realise that the general public have no reason for knowing, and less
reason for caring.

I agree. To be honest, 90% of my AJAX programming has been
for intranets and private web applications with a targeted
user/browser base.



Good one. I have nothing against 2003, I just picked it at
random. Sometimes I get the feeling that a lot of people
avoid new scripting styles (ie: AJAX) in the same way that
they still program their javascript to function correctly
in Netscape 4. I mean, go for it, but I look at the perils
in the 'opposite' way. Whereas that programmer might say
'ignore incapable browsers/users at your peril', I might say
'ignore the application-capabilities that modern users expect
at your peril'.

Design decisions should start with the context, with nothing included or
precluded a priori. Unfortunately we see a lot of people doing only what
they know how to do regardless of the context, because that is all they
know how to do.

Richard.