Tab Content - Common Form Input's

[wdbc]

Script: Tab Content Script
http://www.dynamicdrive.com/dynamici...tabcontent.htm

I have a question, I'd like to use your Tab Content Script. I've successfully installed and got it running, see: http://www.wdbc.com/templates/nav_tab.cfm

I want to use it to search various interfaces on my site and have the text that is inputed on one of the tab content forms input text fields automatically appear on another tab content form if another form is selected. This would be in much that same way that if you type text into Yahoo's search box for the web search function, then tab to the image search function and the text is "stored" across multiple forms. I've been racking my brain and can't seem to figure it out. Any ideas?

Any assitance you might be able to provide is much appreciated.

[jscheuer1]

Do you mean on the same page or across pages?

[wdbc]

It's the same page. Please see my example link at http://www.wdbc.com/templates/nav_tab.cfm where in tab 1 there is a register domain search box, tab 2 there is a Name Spinner Search Box, and Tab 4 there is a site search box. I'd like to have the "qfront" input field in each form within each tab show the text that someone typed into any of the forms in each tab. My tabs are named tab1 thru tab4. Right now, if someone typed something on Tab1, but then went to tab 4 it still shows up un tab1 (via persistence) but doesn't show up in tab4.

Matt

[jscheuer1]

Don't name all the text inputs the same name. Name attributes should be unique. For this demo I am using qfront1, qfront2, and qfront3 for the text input names. Make sure all the text inputs have their type attribute set to:

type="text"

You missed one in your code. When you change the names for the text inputs, don't forget to change them in the onsubmit events and elsewhere (if used elsewhere). Some code can be added somewhere depending upon when you want synchronization of the text inputs to occur. I'd suggest the text input's onkeyup attribute. Put this script in the head:

<script type="text/javascript">
function syncText(val){
if (!document.getElementsByTagName)
return;
texts = document.getElementsByTagName('input');
for (i = 0; i < texts.length; i++)
if (texts[i].name.indexOf('qfront')!==-1&&texts[i].type=='text'&&texts[i].value!==val)
texts[i].value=val
}
</script>

add this event to each text area:

onkeyup="syncText(this.value)"

ex:

<input type="text" size="25" maxlength="63" name="qfront1" value='' tabindex="1" onkeyup="syncText(this.value)">

[wdbc]

John:

In my original code I initially started with them all different, then tried them all the same to see if that would work. I didn't have any javascript as you propose to tie them together and was at a loss on how to do it. I will try this and post whether it worked or not. It all seems to make perfect sense. Thank you for all your help thus far!

Matt

[wdbc]

John:

It worked like a charm! Thank you so much for your assitance and hard work creating this little sync text function script! Your additional script makes these 3 forms on different tabs do exactly what I wanted them to do.

On an aside, I realize now that the unneeded input text variables (qfront1, qfront2...I renamed them all query1, query2 on my site since I got qfront from the DD Tab Content example and didn't like that name) also post to the script on submit but they are really no longer needed. It isn't causing any problems, but is there a way to prevent this? Kind of like a read-only, do not use these bogus input text variable script on submit? Please don't spend any time further on this issue, I am just curious. How might one do that?

Your script plus the DD Tab Content script are far leaner and less complicated that those solely javascript based ones used on Yahoo front page and other sites like www.Whois.sc which are not cross browser supported. Great work!

Matt

[jscheuer1]

I don't fully understand your last post. If you change the names of the input text elements that this script uses, you must also change the line in the script that references the indexOf their names to reflect a common string found in each of the new names. As for 'bogus' text inputs, if you are referring to the ones marked hidden, they may be needed for the forms and/or the tab script to function properly, if not, they may be removed. The attribute readonly can be applied to a text input, it makes it so the user cannot change its value, so I'm not sure how this will benefit you. As I probably missed your point, if you want more advice pertaining to it, please try to be more precise when describing the situation.

[wdbc]

Let's see if I can be clearer, I'm referring to this page on my site which you were kind enough to help with regarding the sync Text: http://www.wdbc.com/templates/nav_tab.cfm. We have query1, query2, etc. which get's synced across the 3 forms on keyup and shows up on the other tabcontent areas. It works great! Thank you again.

Now, trying to explain my question better with an example. Using an example for tabcontent tab1 from page above which is my register domain form script (Note: I've truncated some <option>'s here to simplify. Salient points areas of code are marked in orange and green):

<form action="https://secure.registerapi.com/DDS/controller.php" onSubmit="this.DomainName.value=this.query1.value" method="get" >
<Input Name="DomainName" type="hidden" value="">
<input type="hidden" name="siteid" value="9135">
<b>www.</b> 
<input size="25" maxlength="63" name="query1" value='' tabindex="1" type="text" onkeyup="syncText(this.value)"> 
<b>.</b>
<select class="selectsearch" name="dtld" tabindex="2">
	<OPTION value="" style="color:gray">-any-</OPTION>
	<option>com</option>
	<option>net</option>
	<option>org</option>
</select>
<input type="submit" name="submit" value="Check" tabindex="3">
</form>

I'll use "testing" as what I am searching for using this form as the value for query1. Query1 becomes onSubmit DomainName=testing (green in code above) and the form is processed as by design. I need it to do that, because the real parameter the script is looking for is DomainName. It goes off an searches for available domains. On form submission you get a url like this on the resultant domain search/registration page:

https://secure.registerapi.com/order/register/check.php?DomainName=testing&siteid=9135&query1=testing&dtld=&submit=Check

With both DomainName=testing and query1=testing in the resultant URL for the form get request. Once query1 becomes DomainName, I no longer need query1 as part of the URI request BUT it get's inserted into the get URL request as one of the parameters because query1=testing (in this example) is an input text box. I was wondering if there was a way to get rid of the query1 extirely on submit after it becomes the DomainName so that it doesn't get added into the get/post URL request. Wipping it out, via script to set query1= doesn't help as the empty variable will still post. I simply need the true variable name DomainName and then the other hidden text inputs (siteid, dtld etc). As mentioned, its not a make or break thing and leaving it in doesn't seem to do any harm but it did notice query1 appended. Could you explain a way of possibly fixing that (but please don't create any code or put any more time into it since it isn't a big issue and is more of a curiousity on my part.)

I hope that clears things up a bit.

Matt

P.S. John, thanks again for your help.

[jscheuer1]

Apparently (in IE6 and FF, so should work for most browsers) you can change the name="query#" to id="query#" and the forms will still work but, query#'s value will no longer be sent. This will however stop our syncText function from working. It can be changed to test for id rather than name, then it will work too:

function syncText(val){
if (!document.getElementsByTagName)
return;
texts = document.getElementsByTagName('input');
for (i = 0; i < texts.length; i++)
if (texts[i].id.indexOf('query')!==-1&&texts[i].type=='text'&&texts[i].value!==val)
texts[i].value=val
}

[wdbc]

Thanks again John. I'll do a bit a research with my site to see how much this change would affect my visitors. I suspect changing the sync to an id rather name will only affect a small minority of users so I will probably implement.

Matt