I have a LotusScript agent that retrieves the values to display for the type-ahead feature. This agent uses a view to search for the values. The view is based on a radio button value on the web page. The radio button has a default value, so the agent runs fine.
However, if the radio button changes, the agent still uses the original/default value. I don’t want to refresh the page just to get the radio button value to the back end and processed by the agent.
I thought about the HTTP_Cookie CGI variable and setting the cookie through the onClick event on the radio button, but I think the web page would have to be refreshed to get the correct value to the agent.
I saw these posts, but not sure how to implement or not sure if they will accomplish what I want to do:
Subject: RE: Retrieve radio button value on web page for back end LS agent without refreshing page
This issue is that the field is updated, but the agent that is called – the URL is not updated, since it is in the AJAX object (Ajax4Suggest) – the view name I am passing is the default view…
I need to get the current value of the radio button on the web page and pass to the back end agent without refreshing the page…
Subject: Retrieve radio button value on web page for back end LS agent without refreshing page
You’d need to shoehorn the radio button value into the xmlHttp.open() call in the doRemoteQuery() method. That’s just about the only place that you can get the value dynamically – the constructor takes the value that was in the field when the “new Ajax4Suggest()” is called. The class based on Julian’s code is cool, but it gives up some versatility by trying to be platform-agnostic and by putting too much of the lookup URL into the constructor. Modifying Ajax4Suggest would be easy (a few minutes work), and I’d post a modified version here … except that I do not do GPL. I do free as in beer far too often and free as in speech when appropriate, but my decisions should never prevent another consultant or ISV from hiding a database design if they so desire. Mr. Leleu could easily have incorporated the suggested JavaScript exception clause into the license notice for his class, or used the LGPL or another less restrictive license (one that allows use and modification but does not restrict a downstream developer’s distribution method/license), but since he did not, I will not propagate his code in either its original or a modified form.