 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / September 2007Dynamic Query String Variables?
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 > 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  Signature"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> > julie.sie...@gmail.com wrote: > > So, a user sets their date and party size (or maybe just the party [quoted text clipped - 5 lines] > 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 >> julie.sie...@gmail.com wrote: >> > So, a user sets their date and party size (or maybe just the party [quoted text clipped - 7 lines] > > 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... > >> That's a design error which causes your problem. You can easily > >> build the link to contain your client-side variables, then. [quoted text clipped - 9 lines] > 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 >> julie.sie...@gmail.com wrote: >>> So, a user sets their date and party size (or maybe just the party [quoted text clipped - 6 lines] > > 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. >> No, you can use an accessible link that is only enhanced with script: >> [quoted text clipped - 4 lines] > 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 SignatureAnyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee > >> That's a design error which causes your problem. You can easily build > >> the link to contain your client-side variables, then. [quoted text clipped - 3 lines] > 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 >>> 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. 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, [...] [quoted text clipped - 5 lines] > 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 SignatureAnyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee > > 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? > 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.) > [...] > If that doesn't give enough information about what I'm trying to do, [quoted text clipped - 7 lines] > 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"> </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"> </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 SignatureAnyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee > 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 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[i]].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. 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[i]].href = URLString; } } (Sheesh, what an idiot.) 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. [quoted text clipped - 3 lines] > > } 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 > 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/ > julie.sie...@gmail.com wrote: > [quoted text clipped - 4 lines] > 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 > "Good Man" was right No. > - this really should have been done in AJAX. Thereby excluding even more customers. PointedEars SignatureAnyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee >> "Good Man" was right > [quoted text clipped - 3 lines] > > 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! >>> "Good Man" was right >> [quoted text clipped - 6 lines] > 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. >>>> "Good Man" was right >>> [quoted text clipped - 15 lines] > 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 [quoted text clipped - 7 lines] > 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 <noscript> can 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! > [quoted text clipped - 5 lines] > 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'. >>>>> "Good Man" was right >>>> [quoted text clipped - 14 lines] >> 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). > [quoted text clipped - 3 lines] > 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 [quoted text clipped - 11 lines] > 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. >> AJAX is a great technology for web applications, and can >> be viable and useful on Intranets (where in both cases the [quoted text clipped - 28 lines] > '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. > To other people searching for answers to this problem, this seems to > work, though I'm not sure about compatibility at this point: [quoted text clipped - 10 lines] >> >> } [...] 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[i]).href = URLString; } else { dl["h" + Supplierlist[i]].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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.