Search From a Value List

[Hoosty2]

Is there a way to have be able to search from a value list using the CDML tags? I am trying this to build in some extra web security into the html I have created. Thanks

[MeltDown]

I'm not sure I know what you are asking, but I'll give it a try.

Here is a simple example of a find that will locate records based on a value selected from a value list. The 'All Values' option is optional.

<Form name="myname" method="post" action="FMPRO">

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

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

<input type=hidden name="-format" value="PageYouWantReturned.htm">

<select name="Yoursearchfield" size=1>

<Otion value="*">All values</Option>

[FMP-ValueList: Yoursearchfield, List=YourList]

<Option value="[FMP-ValueListItem]">[FMP-ValueListItem]</Option>

[/FMP-ValueList]

</Select>

<input type="submit" name="-find" value="Find Selected Records">

Good luck -- hope this helps!

[Keith M. Davie]

It helps to know there is a difference between a FileMaker valuelist and the valuelists one can create using html (not cdml). Most people who try to use the FileMaker db valuelist through cdml tags struggle greatly.

Let's say you have a previously existing db file which you now are trying to publish and it has a layout (clerk) which was being used in which a field is formatted as a pop-up valuelist.

Try this.

Make another layout (web). The field which is formatted as a pop-up valuelist should now be designated as a standard field in this new layout (web). If you will select the appropriate value from the layout which has been in use (clerk) and then examine the results of that selection in the layout web, you should see that it is far easier to refer to the standard field in web for a -find or an -edit than it is to deal with the FMValuelist. And, if you will enter a selection from the valuelist (either manually or from a web page) into the standard field in layout web, you will find the appropriate designation has been made upon examination of the field in the layout clerk.

Or you can struggle with trying to get the fmvaluelist to work through cdml tags.

[ June 15, 2001: Message edited by: Keith M. Davie ]

[Keith M. Davie]

Just incidentally, whether the db field has been formatted as a pop-up list, pop-up menu, checkbox or radio buttons in FileMaker, if you will deal with that field through a standard field in a layout (web) which is used as the sole web layout reference, you can approach it from the format file with standard html and a reference to [fmp-field:]. By standard html, I mean you can create an html pop-up, checkboxes or radio buttons which refers to (provides the input or valuelist for) the standard field in your layout web. When the approach to the database file is from the web through web companion, there generally is no good reason to jump between layouts in a db file. Fact is, such a designated layout does not need to be arranged in any special manner and none of the fields (all standard format) need to be sized since users never see the layout. There is no real need to make a fancy design for that layout. To do so is a waste of time and money.

[Anatoli]

RE: There is no real need to make a fancy design for that layout. To do so is a waste of time and money.

PRECISELY!

Just do one single "CGI" layout with all fields from database and you'll be OK forever.

[iBib]

If I may correct Anatoli a little bit...

Make some cgi layouts with exactly the number of fields that you have to use for a certain function, ie. cgi_search, cgi_new, cgi_all etc.

That is a good way of making your format files work faster.

[scratchmalogicalwax]

This is true......data from all fields on a layout is returned to the CGI from the database.

With v large DB's and lots of visitors this could start to glog memory.

Only have the fields you need for the format file in question..... can dramatically improve speed! and doesn't take long to split the database accross layouts especially if you use no formatting or fancy bits (the sort of work copy and paste was made for )

[iBib]

I've tried placing ALL the fields in a pretty large database on one layout and displaying the content of about half the fields through Webcompanion, it was a pain to load. When reducing the number of fields to exactly the amount I needed for the format file it worked a lot faster.

So this really works, and I can't wait much more to get my hands on Filemaker 5.5 Unlimited with it's multi-threaded Webcompanion. That will do miracles to Filemaker and Webcompanion.

[MeltDown]

Calculated fields on the layout can slow response time too. Removing any unneeded calculated fields from the cgi-layout also improves response time.

[Anatoli]

quote:

---

Originally posted by iBib:

If I may correct Anatoli a little bit...

Make some cgi layouts with exactly the number of fields that you have to use for a certain function, ie. cgi_search, cgi_new, cgi_all etc.

That is a good way of making your format files work faster.

---

Is that tested? IMHO WC just request single fields and it is not processing FM layout in Custom Publishing at all.

By switching fields in FileMaker engine the delays will be greater.

Anyone interested in making test for those two concepts?

[Anatoli]

quote:

---

Originally posted by iBib:

I've tried placing ALL the fields in a pretty large database on one layout and displaying the content of about half the fields through Webcompanion, it was a pain to load. When reducing the number of fields to exactly the amount I needed for the format file it worked a lot faster.

So this really works, and I can't wait much more to get my hands on Filemaker 5.5 Unlimited with it's multi-threaded Webcompanion. That will do miracles to Filemaker and Webcompanion.

---

My largest database has around 100 fields and it is fast as db with 10 fields.

Also the overhead when constantly switching layouts for different tasks and different users will be greater.

Maybe I am wrong, but when I will have time, I will do some performance testing.

[Anatoli]

I wouldn’t sleep anyway, so I did testing right away.

To display change of text copied from field A to field B and then back to A:

Layout with 5 fields – split second

Layout with fields > 1000 – split second

I could not spot the difference.

Did you just assume that?

I think the theory of WebCompanion grabbing info from field regardless of number of fields on layout just stands.

The only condition exists: the field must exist on named layout. If it is 1 in 5 on 1 in 1000 – result is instant.

[iBib]

When processing an action, WC will go through ALL the fields in the specified layout. So if you have some fields with a lot of information, like a text field for a news text, it will occupy some rome in the database. And the more information that WC has to process, the less "effective" it will be, effective in this sense is speed.

It's a good rule to keep in mind to make layouts for different web functions so that you can guarantee that your site always is fast and reliable. When those databases begin to swell, and you have a lot of fields which contain a lot of information, it's best to make sure WC doesn't occupy itself with matters which isn't really neccesary.

Even Filemaker Inc. suggests that you split your fields into different layouts to kepp your database on the top.

You don't have to, but it's not time consuming and it will keep you happy when your databases begin to swell...

[Anatoli]

After my tests I am not buying that.

Why will clever relation database work like that?

WC does not "see" the layout. It simply links request [FMP-field: xyz] referenced on layout "abc" as one source of data. Think in 3D with pointers not 2D sequentially.

Until someone creates test, which will show some difference, I am standing on my theory: number of fields on layout is not relevant to processing speed.