By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,635 Members | 1,703 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,635 IT Pros & Developers. It's quick & easy.

Dynamic Query String Variables?

P: n/a
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

Sep 20 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
ju**********@gmail.com wrote:
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
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Sep 20 '07 #2

P: n/a
On Sep 20, 11:58 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
julie.sie...@gmail.com wrote:
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.
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

Sep 20 '07 #3

P: n/a
"ju**********@gmail.com" <ju**********@gmail.comwrote in
news:11*********************@r29g2000hsg.googlegro ups.com:
On Sep 20, 11:58 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>julie.sie...@gmail.com wrote:
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.

This is the design the the client wants.
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...

Sep 20 '07 #4

P: n/a
On Sep 20, 1:41 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
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.

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.
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.
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

Sep 20 '07 #5

P: n/a
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.

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

Sep 20 '07 #6

P: n/a
dn
ju**********@gmail.com wrote:
a bunch...
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.

Anytime a change is made, make a new cookie by incrementing a counter (also
stored as a cookie) and then appending that counter to the cookie name ...
build it from the old one and apply the necessary changes ... that could
give you undo-ability as well...

You could keep your current page design this way at least... just a
thought. Your A links would not have to concern themselves with state
because the cookie has taken care of that already.

by the way, the same exact cookies that you have on the client are passed
with each call to the server and as such are available to your sever side
code as well. Many people do not ever make that connection.

D/
Sep 21 '07 #7

P: n/a
On Sep 20, 10:19 pm, dn <dana...@NoMorePersonalMail.netwrote:
julie.sie...@gmail.com wrote:
a bunch...

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

Sep 21 '07 #8

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.dewrote in
news:46**************@PointedEars.de:
ju**********@gmail.com wrote:
>"Good Man" was right

No.
>- this really should have been done in AJAX.

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

Hey, let's program like it's 2003!
Sep 21 '07 #9

P: n/a
Good Man wrote:
Thomas 'PointedEars' Lahn wrote:
>ju**********@gmail.com wrote:
>>"Good Man" was right

No.
>>- this really should have been done in AJAX.

Thereby excluding even more customers.

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.

Sep 23 '07 #10

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in
news:fd*******************@news.demon.co.uk:
Good Man wrote:
>Thomas 'PointedEars' Lahn wrote:
>>ju**********@gmail.com wrote:
"Good Man" was right

No.

- this really should have been done in AJAX.

Thereby excluding even more customers.

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).
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 agree, and I think we all agree that
mobile browsing is still in the early stage. 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 you are correct, I assume anyone
trying to book flights on a cellphone for this particular application
would be SOL. But how many people are really booking flights via
cellphone? 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.

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).
Really? Either I've done this on my browser (and don't recall doing
so), or I'm misunderstanding? Are you saying that javascript is
disabled by default? If so a simple <noscriptcan alert the users?

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.
I agree. To be honest, 90% of my AJAX programming has been for intranets
and private web applications with a targeted user/browser base.

>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".
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'.
Sep 24 '07 #11

P: n/a
Good Man wrote:
Richard Cornford wrote:
>Good Man wrote:
>>Thomas 'PointedEars' Lahn wrote:
ju**********@gmail.com wrote:
"Good Man" was right

No.

- this really should have been done in AJAX.

Thereby excluding even more customers.

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
^^^^^^
Should have been "available".
>on such devices, plus the cost of connections).

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.
>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).

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 <noscriptcan 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.
>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.

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

>>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".

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.

Sep 30 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.