I'd side with Steve on this one. If the idea is to move a lotta form data,
I'd skip coming up with a self-submitting form scheme, and dive right into
client variables instead. You'll keep all of the traffic on the server side,
and if you use database driven client variables, you'll also be distributing
the workload between your SQL server and your CF box; withouth having to
rely on client-server comm repeatedly.
Think of it like this, every process you can isolate to the server side, is
a process that is 100% browser independent, doesn't rely on a particular
Javascript implementation, and can be made as secure as you desire. (Soapbox
time alert...) As we progress from a web browser paradigm into a wireless
who-knows-what device paradigm, it would be in any developer's best
interests to rely on the client browser as little as possible. If you can do
it on the server side, then do it!
Alan McCollough
Web Programmer
Alaska Native Medical Center
> -----Original Message-----
> From: Bert Dawson [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, July 25, 2000 6:25 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: really long urls!!
>
> You could make the form call itself, include the act_ file if
> IsDefined('attributes.submit_button'), then use an error returned by the
> act_ file to decide whether to CFLOCATION to the next step, or just
> display
> the form again, with the error.
> CFPARAM all the form fields at the start, then set the values of the form
> fields to #attributes.field_name#
>
> Bert
>
> > -----Original Message-----
> > From: Brian P. Doyle [mailto:[EMAIL PROTECTED]]
> > Sent: 25 July 2000 14:58
> > To: [EMAIL PROTECTED]
> > Subject: really long urls!!
> >
> >
> > In redesigning our site to comply with the fusebox
> > architecture I'm finding
> > that I end up creating ridiculously long urls (one that has over 600
> > characters). Essentially these are used in error checking in
> > forms. DSP
> > form file passes the variables via post to an ACT page. That
> > page does all
> > of the error checking and passes all variables back to the
> > preceding form to
> > have the user re-enter the mistaken form fields (all of the
> > other variables
> > are then passed via hidden fields). It's in the pass from
> > the action page
> > back to the dsp (via the index of course) that is creating
> > the really long
> > urls: <cflocation
> > url="index.cfm?fuseaction=blah&more&more&more..etc">
> > Does anyone know a way that I can hide the variables? I
> > thought CFHTTP
> > might do it for me but it does not go to the page its
> > submitting variables
> > to (like a form would).
> >
> > Essentially I'd like to find a way to create a form that
> > submits itself (all
> > of the fields would be hidden fields.)
> >
> > thanks in advance
> >
> >
> >
> >
> > Brian P. Doyle
> > Web Developer
> > SMTnet.com
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
> > --------------------------------------------------------------
> > ----------------
> > To Unsubscribe visit
> > http://www.houseoffusion.com/index.cfm?sidebar=lists&body=list
> > s/fusebox or send a message to
> > [EMAIL PROTECTED] with 'unsubscribe' in the body.
> >
> --------------------------------------------------------------------------
> ----
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
