Tokens

[onclick]

Using tokens has totally escaped my understanding. Can someone explain this to me or direct me to a complete tutorial? I have seen a bunch of bits and pieces, but the total picture is what I need. Thanks!

[Garry Claridge]

Tokens are a way of passing data from page-to-page.

On one page we can assign a Token:

<input type="hidden" name="-token" value="somedata">

One the next page we can use that data from the Token:

My Token value is: [FMP-CurrentToken]<br>

Hope this helps.

Garry

[onclick]

Thanks for the response. Very helpful.

What if I want to pass along what someone entered the "nickname" field, for example? Can you show me the exact code for this nickname field?

Thanks for your help!

[Garry Claridge]

This depends on a couple of things, however this will work for most cases:

<input type="hidden" name="-token" value="[FMP-Field: nickname]">

Good Luck.

Garry

[onclick]

Thanks again.

Actually, this is exactly what I was doing (i think) to no avail. I will recheck my work. It must be something I am doing.

But thanks for being there!

[pcourterelle]

What is puzzling though is that more often than not, or so it seems, the result of

<input type="hidden" name="-token" value="[FMP-Field: nickname]">

is literally [FMP-Field: nickname] when the [fmp-currenttoken] tag is used on a second html page. Which is hardly useful.

The code <input type="hidden" name="-token" value="My Brain Hurts"> combined with [fmp-currentoken] will result in "My Brain Hurts" appearing on the second page.

Any thoughts why?

cheers

pc

[Garry Claridge]

Re: <input type="hidden" name="-token" value="[FMP-Field: nickname]">

For this to work, the page must have been processed by WebCompanion first. This is so the replacement tag "[FMP-Field: nickname]" can be replaced with the field data.

All the best.

Garry

[pcourterelle]

Garry...if the line <input type="hidden" name="-token" value="[fmp-field:nickname]"> is part of the form, should it not be passed through web-companion when the -find or -new request is processed and therefore appear on the -format html page as the contents of the field called nickname?

I guess the simple question is: when is a request passed through WC and when is it not? Does the placement of the tag in the form make a difference (ie , -db first, -lay second, -format third, -token fourth ect)?

cheers

phil

[Garry Claridge]

The order within the form does not matter.

Using "hidden" types, with tokens, is a way of passing "variables" between pages via WebCompanion.

All the best.

Garry

[pcourterelle]

Garry...then we're back to square one, no?

if the form is:

<form>

<form action="FMPro" method="Post">

<input type="hidden" name="-db" value="Nicks.fp5">

<input type="hidden" name="-lay" value="nicks">

<input type="hidden" name="-format" value="results.html">

<input type="hidden" name="-token" value="[FMP-field:Nickname]">

<input type="text" name ="Nickname" value = "">

<input type="submit" name="-new" value="Enter">

</form>

why would the result on the returned -format resutls.html be literally: [FMP-field:Nickname] instead of the contents of the field?

cheers

pc

[CyberSport]

When you're on the page with the above form, as it has been processed by WC, take a look at the source. Surely you will see, for the token tag, value="[fmp-field: nickname]". This is because you are not dealing with a record yet, as it will take until the -new request is processed. Therefore, when the above page is intially processed, it has no data to throw in the nickname field. The [fmp...] tags are "replacement" tags like garry said, but the replacement occurs in the processing of this page, NOT in the processing of the reply page. So, at the time the above page (the new form) is processed, there is no data to replace.

What I would suggest is an inline action at the top the reply page. This inline action would assign the token to be the nickname field of the newly created record, and then you can continue on your merry way.

Here is some sample code to do this:

[FMP-InlineAction:

-db=Nicks.fp5, -lay=nicks, -token={field:Nickname}, -view] [/FMP-inlineaction]

Good luck!

Bevin

[pcourterelle]

Bevin...thanks for the input..If I understand you, your saying the CDML reference is incorrect...According to the CDML reference, "Whatever value you set -Token equal to can be retrieved in the format file by using [fmp-currenttoken]..."

If what you're saying is true than it should apply to the -new request but not a -find request. In the latter case, the record already exists...so why would the token still not work?

pc

[CyberSport]

The CDML reference is right. I think you are jumping the gun as to when you expect to have the token set, though.

In terms of a new record:

There are 2 problems that I can see with how you are doing things. First, how are you calling the page to submit a new record? Are you calling through WC (<A HREF="FMPro?-db=nick.fp5&-lay=nicks&-format=new.htm&-view>) or going straight to: mysite.com/new.htm? If it's the second case, then if you have the code: <input type="hidden" name="-token" value="[FMP-field:nickname]"> there is not a chance for filemaker to process the [fmp-field:nickname] tag (the replacement tag) and you will indeed pass, as text, the value [fmp-field:nickname]. Now, if you use the first method, calling the page through WC, you still aren't working with an active record, so when filemaker tries to replace the contents of the code: [fmp-field:nickname], it has no data and you'll be passing the value: " ", or simply, no data at all.

Therefore, it is on the reply page where you should set the token. This is because now, we have data from an active record to deal with and use for replacement purposes. If, on the reply page, you had some code: <input type="hidden" name="-token" value="[FMP-field:nickname]">, this would now be replaced with whatever the user entered in the field "nickname" on the new record page. However, you'd still have to process this page in a form in order to set the token.

Or, you can use my example above of setting token in the inline action, which would eliminate the need for another page.

-----

Now let's move on to your question about the -find request. Again, [fmp-xxxxx] tags are replacement tags, which means that they are replacing the code with actual contents from the current active record. The replacement of the data occurs on the loading of the page where the replacement tag is located, which means that prior to loading that page, we must be dealing with an active record. Therefore, if all I'm looking at is a -find page, I have yet to select an active record and again have no data to plug in the replacement tag. Filemaker isn't able to, in one uncoded step, remember that you wanted to assign a field value to a token once it performs a find. On the reply page is where I'd set the token, once I have actual current records with which to work, or again I could do this with inline action

---

I know this all might sound rather confusing in the abstract, but just try fooling around a bit with the knowledge that you need an extra step in here, and I think you'll have some success.

Bevin

[Garry Claridge]

PC,

Re: why would the result on the returned -format resutls.html be literally: [FMP-field:Nickname] instead of the contents of the field?

The first form needs to be processed by WC prior to loading into the page, so that the [FMP-Field:Nickname] can be replaced by the data. If you view the source of the page in your browser you will see [FMP-Field:Nickname] in the form instead of the actual data. At this stage it needs to be the data.

Hope this helps.

Garry

[pcourterelle]

Bevin, Garry..thanks for the responses...the mist appears to be clearing...

I'm calling for the reply page with

<input type="Hidden" name="-format" value="somepage.html">

As I understand it, this page cannot be called unless the request goes through WC. How else could the the data retrieved?

Garry, I think some of my confusion is between forms and links in regards to WC....is there a difference between a CDML request processed through a <form> as compared to a link <a href=fmpro?...></a>...? Both are processed by WC, or are they? Should the latter be used for -find, -edit and -new request and the former simply used to display information on the -format page?

My continued thanks...

phil

[Garry Claridge]

Phil,

Both forms and urls can have equal functionality in relation to a request through WebCompanion. Forms usually have a couple of advantages though.

The other note is that replacement tags i.e. [FMP-Field] can only be replaced within a Format file, not the form or a URL as it passes through WebCompanion to call that Format file.

All the best.

Garry

[pcourterelle]

Bevin, Garry...thanks yet again...I was attempting to use a single search form to access info from two dbs using tokens but this has not worked because, as you've both noted above, when the -find request is processed the replacement tag has not been set so the token remains empty. One previous suggestion was to use javascript (which I've only begun learning) so I'll have to see...

you advice and counsel has been welcome and helpful..

cheers

phil

[Garry Claridge]

Phil,

Also, have a look at using [FMP-InlineAction]. The will allow to access another database from within a Format file.

All the best.

Garry

[CyberSport]

Phil,

Here's a simple way to do a search on 2 DBs, using a form on the first page and inline action on the second. In the first DB, we have 3 fields: ID, Last, First. In the second DB, we have 3 fields, as well: ID, Last, First. The purpose of the search will be to search for a specific ID number in the first DB, then in the inline action on the results page, also do a search of a second DB.

---

On the first page, a search form:

<FORM ACTION="FMPro" METHOD="POST">

<P><INPUT TYPE="hidden" NAME="-DB" VALUE="firstDB">

<INPUT TYPE="hidden" NAME="-Lay" VALUE="web">

<INPUT TYPE="hidden" NAME="-Format" VALUE="results.htm">

<INPUT TYPE="hidden" NAME="-Error" VALUE="error.htm">

<INPUT TYPE="hidden" NAME="-Op" VALUE=eq>

<INPUT TYPE="text" NAME="ID" VALUE="">

<INPUT TYPE="submit" NAME="-find" VALUE="Find a Person">

</FORM>

---

page two, results.html

[fmp-record]

Person From First DB

[fmp-field: ID]

[fmp-field: last]

[fmp-field: first]

<--this is assigning the token to be the ID of the person we just found-->

[FMP-InlineAction: -db=firstDB, -lay=web, -token={field:ID}, -view]

<--this tests to see that the token was assigned properly--> token:[fmp-currenttoken]

<--this searches the second DB for the same ID #, using the token-->

[FMP-InlineAction: -db=secondDB, -lay=web, ID= {currenttoken}, -find]

This shows us the results from the second search-->

[fmp-record]

Records from the second DB

[fmp-field: ID]

[fmp-field: last]

[fmp-field: first]

[/fmp-record]

[/FMP-inlineaction]

[/FMP-inlineaction]

[/fmp-record]

---

It'll only take a couple seconds to make the 2 DBs. Give it a whirl.

Good luck!

Bevin

[sricant]

Hi bevin,

I used inline action for token.But i am not getting the required information in the token.may be i am doing something wrong.I am giving my code here.Can any one tell me what's wrong there

<HTML>

<HEAD>

<TITLE>New Record Template</TITLE>

</HEAD>

<BODY>

<H2>Sample New Record Form</H2>

[FMP-InlineAction: -db=people.fp5, -lay=layout1, -token={field:required_username}, -view]

[/FMP-inlineaction]

<P><FORM ACTION="FMPro" METHOD="post">

<P><INPUT TYPE="hidden" NAME="-DB" VALUE="officehours.fp5">

<P><INPUT TYPE="hidden" NAME="-LAY" VALUE="">

<P><INPUT TYPE="hidden" NAME="-FORMAT" VALUE="newreply.htm">

<P>username<BR>

<INPUT TYPE="text" NAME="required_username" VALUE="[FMP-CurrentToken]" SIZE=25>

<P>Name<BR>

<INPUT TYPE="text" NAME="name" VALUE="" SIZE=25>

<P><INPUT TYPE="submit" NAME="-NEW" VALUE="New Record">

</FORM>

</BODY>

</HTML>

Thanks for help.

bye,

sri.

[CyberSport]

okay, i'm assuming there's a page before this that collected the "required username." if that's the case, put the code: [fmp-currenttoken] at the top of the body of your page. that way you can see if it's been passed to this page.

Bevin