Trouble with Meta Tag / Meta Refresh

[dmcwhirt]

I have a Meta tag triggering a URL out of a FileMaker field. This is a cool thing! But...it does not work the same as if this URL is triggered by a user clicking a link. This is the backgound info.

I have a Web page in which users enter their address and 5 digit zip code. When they do this, a record is added to a database called StreetChecker3.fp5. Instantly a calculation field (named URLFindPostalData) puts together a URL that is designed to submit the users's address information to another database in order to find their local legislator. The vehicle to trigger this URL can be a link or a Meta tag.

An example of a URL that the field URLFindPostalData creates is in these brackets [http://www.zzzz.com/Zip/FMPro?-db=PostalZipFour3.fp5&-lay=data&-format=search_results.htm&-error=new_error.htm&TextPartOfAddress=E06060silkey heightsDR&-Op=lte&AddressPrimaryLowNumber3=10&-Op=gte&AddressPrimaryHighNumber3=10&-find]

When a person types in their address and submits it they are using the form NEW.HTM. They are then jumped over to the form NEW_REPLY.HTM which thanks them for their entry and has a "click here" button under which the field "URLFindPostalData" is linked. When they click the link, the search is performed and the legislator names+ come up on a SEARCH_RESULTS.HTM page.

The LINK method works great for any type address. By this I mean addresses that have more than one word in their street name like "Bradley Brook Drive".

Here in brackets is the code that the link generates and how it appears in my IE browser:

[http://www.cbia.com/ZipProject/FMPro?-db=PostalZipFour3.fp5&-lay=data&-format=search_results.htm&-error=new_error.htm&TextPartOfAddress=O06060bradley%20brookDR&-Op=lte&AddressPrim aryLowNumber3=17&-Op=gte&AddressPrimaryHighNumber3=17&-find]

BUT...when I put a META TAG on the NEW_REPLY.HTM page (required by my boss to eliminate the user having to click a second time)it works FINE for street addresses that only have one word in their name like "East Street" but fails for >1.

The meta tag code is:

<META HTTP-EQUIV="refresh" content = " 1; URL=[FMP-Field:URLFindPostalData]" ><<!--this meta tag pauses one second then activates the URL that has been calculated by the field URLFindPostalData-->

It must be something with the spaces but since it fails, i can't see the code in the browser.

Any ideas? thanks!

[Keith M. Davie]

The tags -lop and -op are your problem. In spite of everything which FMI will tell you in their literature, their CDML Reference and their examples, the -lop and -op tags do not work as advertised. The only way to get the -op and -lop tags to work (if they will work at all) is with the addition of JavaScript. They cannot be used effectively with straight html/cdml.

[Garry Claridge]

Would using URL=[FMP-Field:URLFindPostalData,RAW] in the meta tag make any difference?

Just a thought! All the best.

Garry

[Anatoli]

Or maybe even URL=[FMP-Field:URLFindPostalData,URL] form.

[Anatoli]

Try InLines for this.

[dmcwhirt]

thanks for the replies!

Keith, The tags -lop and -op really have been working well for me (at least for this particular project). They do precisely the search that I require. They work well when in a URL that is triggered by a LINK.

But if I try to trigger the same URL using a meta tag trigger, the browser only seems to get PART of the URL - wherever the first space appears, it drops the rest.

garrycl, I tried the meta tag using URL=[FMP-Field:URLFindPostalData,RAW] and here is a sample of what goes to the browser:

[[[ http://www.cbia.com/ZipPr oject/FMPro?-db=PostalZipFour3.fp5&-lay=data&-format=search_results.htm&-error=new_error.htm&TextPartOfAddress=O06035bradley ]]]

- wherever the first space appears, it drops the rest. Worth a try!

Anatoli, I tried the meta tag using URL=[FMP-Field:URLFindPostalData,URL] and here is a sample of what goes to the browser:

[[[ http://www.zzzz.com/ZipProject/http%3a%2f%2fwww.cbia.com%2fZipProject%2fFMPro%3f-db%3dPostalZipFour3.fp5%26-lay%3ddata%26-format%3dsearch%5fresults.htm%26-error%3dnew%5ferror .htm%2 6TextPartOfAddress%3dO06060bradley%20brookDR%26-Op%3dlte%26AddressPrimaryLowNumber3%3d17%26-Op%3dgte%26AddressPrimaryHighNumber3%3d17%26-find ]]]

Unfortunately it did not work. Worth a try too!

All I can think to try next is to alter the calculated field URLFindPostalData

so that it does an elaborate check for more than one word in a street name and actually inserts "%20" into the URL that it creates.

Anyone else run up against this META problem?

[ June 25, 2001: Message edited by: dMcWhirt ]