05-25-2005, 07:18 PM
I have my doubts about whether or not this is a viable option but i figured i'd ask anyways.
here's the scenario: i have this page which hosts a bunch of products and provides info on some of them.
I have another page (same website) where people can request a quote on any of the products offered.
The only info common to both pages is the company name, and the product name. Currently people go to the product search, look around, and then if they want a quote they go to the quoteform page and select company, product, etc.
I want to provide them the ability to click something on the products page and have it load the quoteform and autofill the company name and product they just selected. I don't quite know if this is recommended, or even possible via JS. would a serverside approach be the only way to do this?
Thanks for the input guys
05-25-2005, 07:53 PM
two ways come to mind
1) A ? data string on the end of the url call
2 ) The same sort of thing but with a cookie if both pages in the same domain
05-25-2005, 08:32 PM
does one page open the other? via pop-up method?
05-25-2005, 08:37 PM
right now they are two seperate links from one website
05-25-2005, 08:42 PM
ok, well then
let me look into it and i'l get back to you.
my email is email@example.com
I will look into it when i get home from work.
if it's not fixed within a few hours email me and i'l see what I can do (try to include all three files)
05-25-2005, 09:55 PM
Just did this for someone
same principle although the cookie solution would be better (transparent)
05-25-2005, 10:12 PM
Point being, I wouldn't rely entirely on js if you feel the form prefilling facility is important to your site.
Just did this for someone
Seems to me that if you're using js, you may as well use the DOM to instantly insert the info into the other page/field. It saves a trip to the server that the method posted at SPf uses.
If I have time tomorrow, I'll post an example of the 'PHP w/ js override' (or rather 'js w/ PHP fall-back') method that I'm suggesting.
05-26-2005, 07:30 PM
I would agree Bill but if you have a look at the page itself, JS is needed for virtually any and all functions of this page. that being that, lets assume JS is active.
So where to from here?
VW, i don't know if your approach is applicable or not. it seems to just change the visibility of the layer... my application uses a dynamic form changer and so on.
05-26-2005, 09:21 PM
One of the problems you will find with sending the data as a querry on the url is that there is a restriction (particularly with IE) upon the length of the data which can be passed... I can not recall the limit off the top of my head but for Internet Explorer I believe it is around 268 bytes (a search of the forum should provide the definitive answer tho)... However, if you are not passing any sensitive data nor have concerns regarding the length, passing the data as a querry is a viable solution...
Cookies... Hmmmm... I do not advise using cookies to store the data either... Firstly, there is a 4K limit per cookie but more importantly, many people have their browsers configured to block cookies and thus this method has the potential to cause grief when people start complaining that your page does not work... However, if the data being passed is less than 4K and you are positive that everyone will have cookies enabled, this too is a viable solution...
What I would advise using is the window.name property... This property is available on all browsers, there is no restrictions to the length of data held, nor can a user disable or otherwise restrict its use... However, bear in mind that you must first check and insure that another site has not previously used and failed to clear the window.name property value before you try to use it and insure that you clear these values yourself prior to your visitors leaving your site... If you would like to use this method, try searching the forum, this subject has been discussed several times in the past...
Edit: BTW... There are other tricks which can be used as well... You can open quoteform.html as a named child window of products.html when products.html is opened and move it 1000px's off screen returning focus to products.html and sending the data directly to the now available named window... However, this borders on maliciousness in that this is one method phishers steal data and may be flagged by virus detectors and/or firewalls...
05-26-2005, 10:09 PM
i like. Okay, here's how i see this working. the only things i need passed are the company name, and the product name. That being said i think i see a problem.
because the products are stored in arrays like this one:var Bindicator_Array = new Array("Now please select the desired product","--------------------------->","Phase Tracking Continuous level monitoring (Dry and Liquids)","Load Cells","Yo Yos");i assume that what will have to be passed will actually be the position of the product in the array rather than its actual name.
another thing which may pose a problem is that the products menu on the quoteform is populated onChange via the Company menu (i.e select a company and the products menu changes for that company.) I don't know how this affects the solution.
however the window.name idea seems plausible
05-26-2005, 10:56 PM
I think it might just be easier to take a different approach at this.
Like, lets say for example,
if page1.htm had the drop-down menu BUT
page1.htm also opens page2.htm (which you want to pass the values into)
then it would be much much easier.
and thats just one approach. there are many ways to pass variables between pages (well, many ways if you know how to utalize XMLHTTPRequest OR you have some kind of SSL (server side language) to work with)
05-26-2005, 11:28 PM
hehe, you know... i've been thinking about this for the past day or so and for now I think i'm not going to bother with this. the changes needed would be too drastic and i have other stuff I can worry about before this.
I'll re-open the post in a few months when time is more free-flowing.
Thanks for the input. the solution to this has been provided by you guys, now i'll just attack it when the time is right
05-27-2005, 10:05 AM
JS is needed for virtually any and all functions of this page
I think i'm not going to bother with this. the changes needed would be too drastic and i have other stuff I can worry about before this.
I'll re-open the post in a few months when time is more free-flowing.One thing to mull over in the interim is how to make the page less js dependant. Making access to a page's content reliant on js is a bad idea to begin with, but moves in recent years on behalf of the Disability Desrimination Act (DDA), mean it could also be one that gets the site owner/author into some hot water.
If the site offers a service and is intended to reach an audience beyond yourself, then accessibility is something you need to be thinking about as you devise and construct sites. It is arguably even more important to consider these things when re/building sites from a basic level upwards (i.e. a site that isn't likely to get another major overhaul for the foreseeable future and therefore is unlikely to offer authors/developers another chance to implement fundamental accessibility requirements for a while).
05-27-2005, 03:03 PM
having a major functional disability myself puts me in an awkward position if i choose to play devils advocate :D .... hypocracy being what it is and all.
I'll keep it in mind, however from what I've been told of the demographics regarding the users of this page the % of users incapable of using JS is negligable (that being said, its not and excuse).
Cheers, and thanks for the idea