Question about what happens after you submit?

[ibiubu]

Working on doing an online survey. I use a CDML link which includes the standard -layout and -find at the end. This takes the user to the survey database file and to layout 1. My web page then has a submit form. The user fills in the 2 fields with questions, and hits the submit button which then creates a new record with their answers.

My question is regarding the -lay file that the web browser then goes to after hitting submit. The new -lay file is linked to the new record and is still linked to layout 1, but is there a way to have the new -lay page be linked to a different layout, say layout 2? This way I can have a whole new set of survey questions from layout 2. Then in theory there would be a -edit submit button that they would hit, go to the -lay file and have it based on the next layout, layout 3. More questions, and so on...

Hope I am phrasing this question the correct way.

Larry

[Leb i Sol]

Hi there!

the "lay"out part does not really do much for u on the web..all it does is looks at the layout to make sure that the fields used (on the web) are truly exiting....well, also it gives u the ability to separate/deducate a layout to the web....so

in other words (4 your question) if u don't have any "crutial" fields that need to be separated on different layouts...then might as well include them all on the single layout!

...this is how I understood this whole CDML deal anyway....

all the best!

[EddyB]

Hi Larry,

As you probably know, to set what the next page is after a submit you enter this line in your page:

<INPUT TYPE="hidden" NAME="-Format" VALUE="Name_of_your_next_page.html">

Now, if the new page is to work from a different layout on your database, just enter the following line into your new page

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

I used this method recently. I was creating an online quiz which included hundreds of question. Trying to put this onto one page was a nightmare, 1- because of the way it looked (very ugly) and 2- it included lots of calculations to self-mark the quiz so when submitting answers onto 1 layout which included all fields including the calcs, it could take up to 6 minutes to receive the next page on the web.

So I split it into several layouts and pages.

So layout 2 included Qu's 1-10 so did Web Page 2, layout 3 included Qu's 11-20, so did Web Page 3 and so on.

I used the example above and it worked fine, but as Leb i Sol said if you have no particular reason, i.e. speed problems, for splitting the questions up onto different layouts, then don't, it's all fine on 1 layout. - If it isn't broke, don't try to fix it!

Ed.

[Unable]

"Trying to put this onto one page was a nightmare, 1- because of the way it looked (very ugly) and 2- it included lots of calculations to self-mark the quiz so when submitting answers onto 1 layout which included all fields including the calcs, it could take up to 6 minutes to receive the next page on the web."

EddyB, I hate to say this but, for CWP (which is what CDML is all about since IWP allows no direct control over code) what you have offered is pretty lame advice. It does not support the facts.

re: point (1), it looked (very ugly): as far as my browser, or anyone else's broswer is conserned, it is an application on my machine and neither the application nor my machine contains your db file(s). Therefore, as long as the fields can be found by the browser application's ability to interpret your HTML/CDML and find the fields on any one layout in the db file of the server - no matter where that db file resides with the server - that is all that matters to my machine and browser application. As the client, I will never see the db file's layout. Successful CWP solutions have nothing to do with layout aesthetics. The data which is displayed by the browser depends on HTML and CDML and field accessibility.

re: point (2), 6 minutes to receive: If you are suffering with calculations which are slowing down the processing, then you have erred in your solution design. If the calc fields are "unstored" there should be no load problem. If the calc fields are "unstored" and you are experiencing six minute page loading problems, look to your solution design. There must be a flaw in your solution design. Successful solution design does not have problems.

In CWP I have yet to encounter a solution in which one un-aesthetic web dedicated layout per db file was not sufficient for a successful solution design. I'm not saying that a need for a second layout may not arise, just that I have not encountered that situation.

[EddyB]

Thanks for your comments Unable but you misunderstood.

1) because of the way it looked (ugly)

I was not commenting on the FMP layout, i was talking about the web page.

Hence the comment "Trying to put this onto one PAGE " rather than "Trying to put this onto one LAYOUT". So yes, the users will see this. Would you like to see several hundreds of questions on one page? - bit painful on the eyes I should think.

When posting about FM on the web I would have thought users would have realised the difference between page and layout - page meaning web page, layout meaning FM layout - maybe I'm wrong?

2) My problems with 6 minutes response were cured when splitting up the fields onto layouts - so I was happy with that a cure to my solution - whether it be right or wrong in your eyes. I was only sharing my experience.

So you may want to rethink your comment - "pretty lame advice. It does not support the facts." My fix solved my problem - and that's a fact!

AND...

The original question:

"is there a way to have the new -lay page be linked to a different layout, say layout 2"

was answered in my post, "lame advice" :???

Ed

[Steve T.]

Hi, Larry! IMHO, there's no right or wrong way here. Using 1 layout is certainly easier to reference and easier to debug (I've forgotten to add fields to the layout a number of times and wasted time trying to figure out non-existent errors in my code) but there's nothing wrong with using as many layouts as you need/desire. As EddyB says, just put the -lay tag on the form page preceding the -format page. When you specify a layout (and you don't need to), only the fields on that layout are accessible. FM, Inc. does not recommend you rely upon this as security, though.

I don't know if it's good form or not (pun!) but I've put the whole startup tag set (-db, -lay, -error, -sortfield, -max, etc.) on cascading forms in series before and not had any problems.

--ST

[ibiubu]

Thanks for all the suggestions. It looks like the single "Web" layout will work great for this solution. I have the other layouts for when the database is accessed from FileMaker, and I consolidated all the fields into a single "Web" layout for web access.

Works great.

Thanks.

[Garry Claridge]

Re: In CWP I have yet to encounter a solution in which one un-aesthetic web dedicated layout per db file was not sufficient for a successful solution design

Sometimes I will use more than one Layout for a Web application. This could be for efficiency reasons; i.e. no Calculated/Unindexed fields on one Layout, or only a couple on another. Sometimes I may only have one field on a Layout. (Maybe I'm being too paranoid about efficiency )

All the best.

Garry

[Unable]

Here is a concept for efficiency Garry. Do not incluce calc fields on your web layout. Talk about efficiency. Wow!

I would suggest that anyone interested in this concept get the example I recently posted in the Sample Files Forum: CDML to Track browser hits on per record basis

There are two db files. Each has one layout. Each has a calculated field, c_sum. Remove that field from each layout (do not delete from the "Define fields for 'dbname'" box). Now that field does not exist on any layout, but only as a definition.

Check it out!

Run the application through your browser. On the results page you will encounter a line which will read something like:

"The edit has incremented that number to 6".

The code for that reads:

<p>The edit has incremented that number to [fmp-field:c_sum]

In other words, this calc_field does not need to appear on any layout to function or display data on a browser page.

Everyone, please try to extend the implications of that for your solution needs.

Additionally I have loaded over a hundred fields from a single layout, including calc fields and repeating fields, with no problem.

And I said that my experience does not mean it may not sometime be necessary, just that I had not encountered the problem. Please do not shoot me because I CMA. Read carefully what I wrote.