Can you easily pass a parameter to a WebDirect solution?

[xochi]

In IWP it was nearly impossible to pass a simple parameter to a database while opening it.

e.g. you couldn't simply set another value in the URL and access it from within IWP:

http://mycompany.com/fmi/iwp/cgi?-db=MyDatabase&-loadframes&foobar=xxx  

There was no way to read the value of "foobar=xxx".

 

Any improvement in WebDirect?

[rwoods]

Thanks for posting this xochi. I too would LOVE this to be possible. I am trying to design a 'Click and Reserve' system to allow customers to click a button on our web site and see live stock information generated from FMP hosted in our office. I would like to pass our stock code to FMP 13 Server in the URL (your foobar parameter) and then have Filemaker go to a particular layout and search for that parameter in our stock file, thus displaying automatically the correct stock record with live stock information.

 

It seems you can do the following :-

 

http://<IP address>:<Port number>/fmi/webd#<database name>&lay=<layout name>&viewstyle=<view>&record=<record number>&mode=<mode>

 

However, the Record Number seems pretty useless as a parameter, unless perhaps you wanted to pass '1' to always show the first record. The record number changes based on how many records are in the found set.

 

I could do what I want to do in custom web publishing with PHP as you can pass parameters in the URL, but it seems such shame when WebDirect does 99.99% of what I need to do without custom coding.

[James Gill]

100% agree.  Without the ability of WebDirect to read parameters from the URL, creating relatively simple tasks such as token-based password resets and 2-factor authentication is all but impossible and, in this day and age, completely required for any web app.

[KaosMaker]

There is a workaround for *some* purposes, that I'm using.

 

Create a new table that has a field to contain your parameter(s).

Create a CWP page that does nothing but take a PHP parameter(s), and perform a script that creates a new record, and sets that field with the parameter.

In the PHP page, capture the record ID of that new record.

Then, in the PHP page, construct the url for WebDirect to load a layout in your new table, with that record ID as a parameter as described above.

In that layout, set an OnRecordLoad script to fire a script and use the parameter you've set in that record. What you do with it from there is up to you, even up to and including using one of the parameters to define which script to call in turn, and pass the remaining parameters on to.

 

**NOTE** Make sure your OnRecordLoad script takes you away from the parameter table, since you don't want users to linger there.

**NOTE** Make sure you put an Exit Script condition in your OnRecordLoad script if Get(RecordID) = 1, since WebDirect ALWAYS initially loads the first record of any layout BEFORE going to the Record ID in the URL. This is useful to know for anyone who wants to pass a non-default Record ID into WebDirect.

 

EDIT:

 

Sorry, correction. After further testing, it appears that, as rwoods said (if I'd read more closely), the WebDirect URL requires a Record Number, NOT Record ID. While this probably doesn't matter for a table you only intend to create in, and never delete, it is worth noting that to properly access the Record Number from the PHP page, the easiest way would be to run a script that finds the desired record, Shows All Records, and then returns the Get(RecordNumber). Sorry for the added complexity.

[William Keyte]

Yes, there really are some worrying omissions here. For me, the most serious (as James said above) the lack of facility for passing a username and password for force-logging-in a user. I know this is inherently insecure as you're passing this in plain text but I've developed a set of alias accounts which are re-constructed regularly consisting of randomly calculated characters for precisely this purpose. Present a single clickable URL to a user in an email allowing them to dive straight into a database. In this case, the database doesn't need to be that secure anyway.

These are the URL schema that are offered from the WebDirect guide:

http://<IP address>:<Port number>/fmi/webd/

http://<IP address>:<Port number>/fmi/webd#<database name>

http://<IP address>:<Port
number>/fmi/webd#<database name>&lay=<layout name>&viewstyle=<vie
w>&record=<record number>&mode=<mode>

I'm sure it would be possible to engineer something by passing a user number as the record number to a a table of users - landing on their own user record and thence picking up further context parameters; but what a hassle. Once again: implement something but don't quite complete it! Geez.

I'm being unfair - coz' there are some great things about 13. :-)

 

Will

[HazMatt]

I agree that the inability to pass custom parameters upon launching a WebDirect solution is needed!

 

I am working on replacing our broken PHP job application form with WebDirect and here's what I'm doing, which might work for you if you do not need to pass dynamic parameters:

 

1)  Create a table "webdirect_solutions" and create a couple of records.

2)  In the second record, enter a value "New Job Application" in the Action field.  (this will be the static script parameter)

3)  Create a layout "lyt_WebDirect_Landing_Page" and add a script trigger for OnRecordLoad, which passes the value of the Action field.

4)  Create the trigger script, "Launch WebDirect Solution Action" that takes the passed script parameter and goes to a different layout, or whatever you want.

 

So, your URL would look something like this:

http://<IP address>:<Port number>/fmi/webd#<database name>&lay=lyt_WebDirect_Landing_Page&viewstyle=form&record=2&mode=browse

 

Basically, you could set up an unlimited number of static parameters (or "actions" as I call them) stored in those records, which allows you to change only the record number in the URL that launches the WebDirect solution.  This approach has some drawbacks:

 

• Deleting a 'solution' record will bump the remaining solution record numbers down, so any stored URLs would have to be updated to suit.

• Only values that you specify in each 'solution' record can be passed.  No dynamic values.

• Maybe other drawbacks I haven't thought of…  I'm only getting started with WebDirect!

[KaosMaker]

HazMatt, that's pretty much the only way I've found to do it, as well. In my post above, I do describe a way you can dynamically access the current Record Number for a given parameter, but it uses CWP. It's a pretty simple PHP page, but still, it may not meet your needs.

 

As for dynamic values, there is a way, but it also uses CWP. Have the URL pass a parameter to a PHP page, which in turn uses CWP to add a record to a Parameters table, setting the Parameter field (or whatever you want to call it if Parameters::Parameter is too tacky) to the parameter you passed in. Have it return the record number to the PHP page, and then access THAT record number via the WebDirect URL.

 

Example: www.website.com/page.php?x=314159265359 will create a new record in the Parameters table, setting the data field to 314159265259, and returning record number 1123 (since it is the 1123rd record created since the last purge). Then your PHP page directs you to www.website.com/fmi/webd#Parameters&lay=Load&viewstyle=form&record=1123&mode=browse

 

Of course, then your OnRecordLoad script fires and proceeds however you desire.

 

Just a reminder that your OnRecordLoad script should exempt record number 1, since it ALWAYS loads that first. It seems that's what you're doing in your example, but I just wanted to remind others who might not realize.

 

Thanks for digging further into this, and good luck with the adventure that is WebDirect!

[HazMatt]

Yeah, seems like a hack no matter which way you 'slice' it, eh?  

 

Thanks for pointing out the record #1 load issue—I do have this in my script:

Get(RecordNumber) = 1
  #WebDirect always loads record #1 regardless of record number specified
  Exit Script []
End If