Dynamic Query String Variables?

Discussion in 'Javascript' started by julie.siebel@gmail.com, Sep 20, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. 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>
    Thomas 'PointedEars' Lahn, Sep 20, 2007
    #2
    1. Advertising

  3. Guest

    On Sep 20, 11:58 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > 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, 2007
    #3
  4. wrote:
    > On Sep 20, 11:58 am, Thomas 'PointedEars' Lahn <>
    > wrote:
    >> 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 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:
    >>
    >> <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,


    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
    --
    Anyone 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
    Thomas 'PointedEars' Lahn, Sep 20, 2007
    #4
  5. Guest

    On Sep 20, 1:41 pm, Thomas 'PointedEars' Lahn <>
    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, 2007
    #5
  6. Guest

    > >> 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, 2007
    #6
  7. wrote:
    > On Sep 20, 1:41 pm, Thomas 'PointedEars' Lahn <>
    > wrote:
    >>> 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, [...]

    >> 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
    --
    Anyone 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
    Thomas 'PointedEars' Lahn, Sep 20, 2007
    #7
  8. Guest


    > > 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.)
    , Sep 20, 2007
    #8
  9. wrote:
    > [...]
    > 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
    --
    Anyone 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
    Thomas 'PointedEars' Lahn, Sep 20, 2007
    #9
  10. Guest

    > 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
    , Sep 21, 2007
    #10
  11. Guest

    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.
    , Sep 21, 2007
    #11
  12. Guest

    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.)
    , Sep 21, 2007
    #12
  13. Guest

    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
    , Sep 21, 2007
    #13
  14. pr Guest

    wrote:
    > 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.
    pr, Sep 21, 2007
    #14
  15. Guest

    On Sep 20, 10:19 pm, dn <> wrote:
    > 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, 2007
    #15
  16. wrote:
    > "Good Man" was right


    No.

    > - this really should have been done in AJAX.


    Thereby excluding even more customers.


    PointedEars
    --
    Anyone 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
    Thomas 'PointedEars' Lahn, Sep 21, 2007
    #16
  17. Good Man wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> 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.
    Richard Cornford, Sep 23, 2007
    #17
  18. Good Man wrote:
    > Richard Cornford wrote:
    >> Good Man wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> 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 <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
    >> 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.
    Richard Cornford, Sep 30, 2007
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?VGVyb3M=?=

    Dynamic Variables? OR Dynamic Controls

    =?Utf-8?B?VGVyb3M=?=, Aug 10, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    419
    Scott Allen
    Aug 10, 2004
  2. Anonymous
    Replies:
    0
    Views:
    1,457
    Anonymous
    Oct 13, 2005
  3. Replies:
    9
    Views:
    936
  4. roadrunner
    Replies:
    1
    Views:
    235
    Gunnar Hjalmarsson
    Feb 8, 2006
  5. nick
    Replies:
    1
    Views:
    452
    David Mark
    Feb 13, 2011
Loading...

Share This Page