you may want to look at CF's xml capabilities and just storing the xml
string in one hidden form field per page. any new fields per form can
be added as nodes to the whole xml string, which gets parsed at the
end of the process.
G
On 4/13/05, Peter Galipo <[EMAIL PROTECTED]> wrote:
> I do something like this
>
> session.stApplicationState.personalDetails =
> duplicate(arguments.form);
>
> as the entire app has about 50 form fields I wouldn't like to start
> hiding so many fields. Easier just to pop the entire form into a
> structure.
>
> >>> [EMAIL PROTECTED] 13/04/2005 8:34 am >>>
> My long non-best-practice method:
>
> Each form has all the form fields from the other forms as hidden form
> fields. In the processing of each form, set a variable called
> "SubmittedFormFieldName" (Where FormFieldName is the name of the form
> field) to the value of the form field. Then at the top of the page
> after checking to see if the forms have been submitted and before the
> forms are rendered, for each of the form fields, I go
> <cfif not isdefined ("SubmittedFormFieldName")>
> <cfset SubmittedFormFieldName = ""> (or 0 if numeric)
> </cfif>
>
> Each form field then has a the default value of
> #SubmittedFormFieldName#.
>
> Mind you, I also do all this on the one .cfm.
>
> Chad
> who feels like Mr. Not-Best-Practice
>
> On 4/13/05, Barry Beattie <[EMAIL PROTECTED]> wrote:
> >
> > >> Yes, you should be saving the state if the user goes backwards
> >
> > I was thinking about stealing yet another asp.net idea in having a
> "state bag" (almost a feedbag...) that did this. The origional idea is
> quite cute - eg: when dropdowns are selected the selected index is
> stored inside a "__VIEWSTATE" hidden form field, filled in text box
> values are stored as well. The hidden form field is posted back to the
> same page where it is repopulated (hence maintaining "state") and is
> built into the asp.net framework so you don't have to worry about it.
> >
> > multi-page wizards now become one very dynamic form and all values
> end up in __VIEWSTATE until it's time to process (final form submit).
> Makes traveling back thru the wizard pages (and re-populating the form)
> a breeze. Much cleaner than session variables...
> >
> > maybe an idea or two to be "inspired" by, perhaps?
> >
> > cheers
> > barry.b
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of Chad
> > > Renando
> > > Sent: Tuesday, 12 April 2005 4:00 PM
> > > To: CFAussie Mailing List
> > > Subject: [cfaussie] Re: saving state
> > >
> > >
> > > Yes. I had the same situation. Give the user's the option and
> they
> > > will bounce back and forth like crazy, and complain if they can't
> and
> > > complain if they lose data.
> > >
> > > Chad
> > >
> > > On Apr 12, 2005 11:08 AM, Darryl Lyons
> > > <[EMAIL PROTECTED]> wrote:
> > > > Yes, you should be saving the state if the user goes backwards.
> I
> > > > generally do not apply any validation rules to the content
> > > on the previous
> > > > page unless the user is going forwards.
> > > >
> > > > Darryl
> > > > http://dangermoose.blogspot.com
> > > >
> > > > [EMAIL PROTECTED] wrote on
> > > 12/04/2005 10:38:23 AM:
> > > >
> > > > > Morning All,
> > > > >
> > > > > I have an app which takes the user thru an 8 step
> > > process. Each step is
> > > > > made
> > > > > up of various forms. on each page the user can either
> > > navigate to the
> > > > > next page or back
> > > > > to the previous page. Currently, when the user navigates
> > > forward I
> > > > > save the contents
> > > > > of the previous page into a structure.
> > > > >
> > > > > My question is, should I also be saving the contents of a
> > > page if the
> > > > > user navigates backwards.
> > > > > eg. On page two the users enters some data and then
> > > decides to go back
> > > > > to page 1. Should I be
> > > > > saving the content of page two when the user navigates
> backwards?
> > > > >
> > > > > Pete
> > > > >
> > > > >
> > > > > >>> [EMAIL PROTECTED] 12/04/2005 7:21 am >>>
> > > > > Ron i just checked my JVM settings, and JRUN installed
> > > with JVM 1.42_05
> > > > > so
> > > > > its running off the version we want it to. Which means i am
> now
> > > > > officially
> > > > > stumped lol
> > > > >
> > > > > How tried messing around with the jrun.xml file in the
> > > server instance
> > > > > but
> > > > > seems to do nothing...its almost as though the
> > > certificate just isn't
> > > > > being
> > > > > found or isn't being used....and its very hard to see
> > > whats happening
> > > > > at
> > > > > that level of the handshake.
> > > > >
> > > > >
> > > > >
> > > > > "Ron Yoon" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]
> > > > >
> > > > > Phil,
> > > > >
> > > > > I can only speak for CFMX 6.1 - and it was a little while
> > > ago when I
> > > > > took a
> > > > > stab at this but...
> > > > >
> > > > > 1. Try importing the acutal LDAP server cert (not the CA
> > > cert) into
> > > > > cacerts
> > > > > {CFMX INSTALL}\runtime\jre\lib\security\
> > > > >
> > > > > 2. Try using JVM 1.4.2_04 or 1.4.2_05 (1.4.2_06 has
> > > LDAP/SSL specific
> > > > > issues
> > > > > with CFMX last time I checked) - to do this re-jig the
> > > line entry in
> > > > > {CFMX
> > > > > INSTALL}\runtime\bin\jvm.config (backup this file just in
> > > case you f^&k
> > > > > it
> > > > > up)
> > > > >
> > > > > SO:
> > > > >
> > > > > java.home=C:/CFusionMX/runtime/jre
> > > > >
> > > > > SHOULD BE:
> > > > >
> > > > > java.home=C:/Program Files/Java/j2re1.4.2_04 (or whatever
> version)
> > > > >
> > > > > 3. Restart jrun services
> > > > >
> > > > > 4. Pray
> > > > >
> > > > > Apart from that, I'm all out of ideas.
> > > > >
> > > > > Ron
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] Behalf Of
> Phil
> > > > > Rasmussen
> > > > > Sent: Monday, 11 April 2005 4:36 PM
> > > > > To: CFAussie Mailing List
> > > > > Subject: [cfaussie] JRUN4 certificate store problems for SSL
> over
> > > > > CFHTTP
> > > > >
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I have been on this problem at work for almost 16 hours
> > > now and its
> > > > > driving
> > > > > me insane. I am trying to use CFHTTP to create an SSL
> > > connection to a
> > > > > payment gateway and the payment gateway requires a client
> > > certificate
> > > > > needs
> > > > > to be attached at my end to make a successful request.
> > > The certificate
> > > > > is
> > > > > generated from within their own network and is not from one of
> the
> > > > > trusted
> > > > > authorities in the cacerts file in the jrun installation.
> > > > >
> > > > > I have read countless articles on how to use keytool.exe
> > > to add new
> > > > > X.509
> > > > > certificates to the cacerts store so that coldfusion
> > > knows to use the
> > > > > correct certificate when performing the authentication,
> > > however, it
> > > > > just
> > > > > doesn't want to play ball. I then read just a few hours
> > > ago that if you
> > > > > have
> > > > > ColdFusion deployed on top of an existing Jrun4 server
> > > (as I do) then
> > > > > the
> > > > > cacerts file is not actually used, and rather you have to
> > > go hunting
> > > > > for the
> > > > > keystore specified in the jrun.xml file in your coldfusion
> server
> > > > > instance
> > > > > under jrun... phew!
> > > > >
> > > > > Have located the trustStore file under jrun4/lib and added the
> > > > > certificate
> > > > > to that, restarted Jrun and CF and still I get connection
> > > failures....i
> > > > > am
> > > > > out of ideas now. If anyone can shed some light on this
> > > it would be a
> > > > > godsend at this point.
> > > > >
> > > > > My installation is Jrun4 server with Flex, CFMX6.1, and CFMX7
> all
> > > > > deployed
> > > > > as separate server instances.
> > > > >
> > > > > Thanks In advance,
> > > > >
> > > > > Phil
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > You are currently subscribed to cfaussie as:
> [EMAIL PROTECTED]
> > > > > To unsubscribe send a blank email to
> > > > > [EMAIL PROTECTED]
> > > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > You are currently subscribed to cfaussie as:
> > > [EMAIL PROTECTED]
> > > > >
> > > > > To unsubscribe send a blank email to
> > > > > [EMAIL PROTECTED]
> > > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > > >
> > > > > ---
> > > > > You are currently subscribed to cfaussie as:
> > > > [EMAIL PROTECTED]
> > > > > To unsubscribe send a blank email to
> > > > [EMAIL PROTECTED]
> > > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > >
> > > > To unsubscribe from this email please forward this email to
> > > [EMAIL PROTECTED]
> > > >
> > > > This email message is confidential and may be privileged.
> > > Unauthorised use, copying or distribution of any part of this
> email
> > > > including attachments is prohibited. If you are not the
> > > intended recipient please forward the email to
> > > [EMAIL PROTECTED]
> > > > and delete the original.
> > > >
> > > > ABN AMRO Morgans Limited and its associates hold or may
> > > hold securities in the companies/trusts mentioned herein. Any
> general
> > > > advice included in this email has been prepared without
> > > taking into account your objectives, financial situation or
> > > needs. Before
> > > > acting on the advice, you should consider its
> > > appropriateness or discuss with one of our investment advisors.
> > > >
> > > > To the extent permitted by law we exclude (and where the
> > > law does not permit an exclusion, limit to the extent
> > > permitted by law) all
> > > > liability for any direct, indirect and consequential costs,
> > > losses, damages and expenses incurred in any way (including
> > > but not limited
> > > > to that arising from negligence), connected with any use or
> > > access to this email or any reliance on information contained
> > > in this email
> > > > or any attachments.
> > > >
> > > > ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A
> > > Participant of ASX Group A Principal Member of the
> > > > Financial Planning Association
> > > >
> > > >
> > > > ---
> > > > You are currently subscribed to cfaussie as:
> [EMAIL PROTECTED]
> > > > To unsubscribe send a blank email to
> > > [EMAIL PROTECTED]
> > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > >
> > >
> > > ---
> > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
>
> > > To unsubscribe send a blank email to
> > > [EMAIL PROTECTED]
> > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > >
> >
> > ---
> > You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> > To unsubscribe send a blank email to
> [EMAIL PROTECTED]
> > Aussie Macromedia Developers: http://lists.daemon.com.au/
> >
>
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
>
> To unsubscribe send a blank email to
> [EMAIL PROTECTED]
> Aussie Macromedia Developers: http://lists.daemon.com.au/
>
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to [EMAIL PROTECTED]
> Aussie Macromedia Developers: http://lists.daemon.com.au/
>
---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
