Not to mention that if you're doing any kind of error checking, you've lost all your form elements in a cflocation unless you did a forward. Bryan, I prefer the method you were talking about as well.
I was experimenting with submitting to a cfc-based controller method a while back, and had three structures that I tried:
1) the cfc processes incoming data and then cflocations to the display page; in the case of a redisplay (error, etc.), the form fields are lost
2) a modification of the above, but first storing the data required for redisplay in a session-scope structure that is retrieved by the display page; but the display page always needs to check for this structure, so it (to some extent) is acting like its own controller
3) I tried getPageContext().forward("display.cfm") instead of cflocation, which preserved the form fields and everything; however, when the display page is chosen (next, prev, redisplay?) the url does not change -- breaking the ability for users to bookmark, or controllers to gauge where they are based on the CGI vars.
In the end, I modified #2 so that every display page submits to itself and not the cfc, but the first thing it does is it calls its controller and the controller processes incoming data then delivers the data the display needs to work. This maintains the form vars for inline redisplay without session voodoo, and doesn't break the bookmarking ability. But it means that all my experiments with submitting to the cfc brought me full around to display pages submitting to themselves.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
