Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 8612 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I'm a little new to this, so please bear with me.

I have a web page where I want people to be able to log in. They enter a user name and password. So my -lay is "login", a fmp layout with just those two values. My -format is "loginreply.html". After the person enters their data, loginreply displays properly, but the only fields that show up on the screen are the password and username they just entered. What I want is for the data from a different layout to display additional fields (name, address, etc). These fields are in a layout called main. I have tried, in the loginreply.html, to set -lay to "main" but the data still won't display.

If I change the login layout to "main" and add the password and user name fields to it that works fine, but is not what I want.

This is probably simple, thanks for the help

Joe

Posted

Well, mostly beacuse all the filemaker documentation I have says to only request as much info as you need. I plan to end up with about 6-10 pages of additional data I would like edited by the user, with each page of my web site displaying info from a matching layout in filemaker.

Does that make any sense?

Posted

From my other posting:

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.

Posted

Anatoli is correct in saying that the performance difference is minimal (fractions of a second) if you are using a powerful-ish server with a decent amount of memory. So there is no real problem with sticking all your fields on one layout.

I split my databases between multiple layouts - thats just the way I prefer to do it..........the way i get around the problem you are having is to put the fields requied for the following format file on the layout before. I you have records that people return to to amend and you use multiple format files it is the only way round it without complicating things with FMP-Inlines.

Posted

There is absolutely nothing wrong with multiple layouts, but you must all the time track that.

My way has 1 big advantage -- never missing field, not wrong layout and never typo.

I have all in one layout "CGI". That is common name for some kind of back processing.

I am just creating this CGI layout and FM cannot be on the wrong one.

FM automatically creates the names of fields. When copying them to the HTML layout, it is just simple copy/paste step, so I never ever had problem with typo.

All that because I am lazy person, who will get to unbelievable lengths and 16 hour workday just to be lazy...

Posted

Ok. I guess I can buy that (but seems to make a few cdml commands superfluous).

I have everything so it now works. My initial page loads as an -edit, then the "submit" button uses the the format for page two. In this manner I can move through all six pages of the record's data. This seems kind of inelligant though. How can I jump to a page using a button but still have any changed data on the current page saved?

Joe

Posted

Anatoli

I agree that one layout for the web is best. But occasionally I come across a problem where a second web layout is necessary.

Lets say I have a "web" layout where all the web-required fields are (fields used in the custom HTML format files). Everything works fine. I then add a portal with a related field on the web layout, and the related field has a validation condition (like "not empty"). Now when I try to create a new record in the master database over the web, the validation on the related field brings up an error and prevents the action from being completed, even though I'm not making a record in the related database nor changing the related field in any way.

The only way around the problem I found is to have a second "web" layout with the portal/related field on it -- to keep it away from the other fields -- and call this layout in the custm html format file only when necessary.

This trap has caught me out a couple of times now, it's a real head-scratcher. Who'd think that puting a portal or related field on a layout would break the whole database!

Posted

Vaughan,

I am sure, that problem with "required" or "not empty" hit anyone during the years.

As you get from my post, I am lazy so I am using only 1 layout if that works. But it is not guaranteed, that it will be sufficient and work always.

I did stopped to use FM validations. Sometimes I am using calculating fields to do complex validation; sometimes I am using only JavaScript validation.

Last word to anyone: use what works for you! But do not blame FM or somebody, when you make bad design decision.

Anatoli smile.gif" border="0

This topic is 8612 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.