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/