We've built a framework that gets around this, without using HIDDEN form
fields. It's quite complex so I'll give a high level description, it should
give you some ideas. Our framework works on the basis that every page
consists of a single form that submits to itself (same URL). All page/form
elements are constructed from a library of class objects written in PHP.
These elements may, or may not, have a value. By default we make all of
these values session variables, so we are gauranteed that the values will be
there on the next page submission. We prefix these session variables with a
unique prefix.
If a page goes to another URL then our framework recognises that the URL has
changed and deletes all of the previous pages session variables by
identifying them with the defined prefix.
All of this is hidden away from the programmer, the behaviour is
encapsulated in our frameworks base classes. When a page loads it begins by
constructing the page element objects, during construction the base classes
check for the existance for a session variable value. If it exists then that
particular form object is assigned that value. The application code can set
values for form objects, but it does this through accessor functions, which
in turn ensure that the new value is propogated to the session variable. If
a value is POSTed to the page then the framework grabs the value and assigns
it to the form object via the accessor function (hence it's now a session
variable once again).
We took it a little step further and added similar caching of data objects,
so on a page reload the same result sets are used from the last time around
(if desired) rather than having to make another round trip to the database.
The programmer only has to pick the relevant form objects that they are
interested in and position them on the page using a layout table object. The
framework takes responsibilty for maintaining state and the coder just has
write the app. logic.
This is a very high level description, the solution is not trivial and threw
up a number of issues that we've successfully solved. For example, we
implemented meaningful name-mangling of form objects to prevent the creation
of multiple form objects with the same name. We have implemented an event
driven mechanism so that 'onclick' routines are called for those objects
that caused a form submission (be that a button, link or listbox selection).
If you want to let a user go to another screen then you stick a redirect in
the 'onclick' event for that object. Of course, this means that nothing can
be displayed before hand, so our framework ensures that nothing is sent to
the screen until all application code has run. All screen objects can have
javascript associated with themselves, this code is all output together in
the correct part of the HTML generation. There are a bunch of other features
that we have. This OO approach has saved us a great deal of time.
It works surprisingly well and means that we spend 90% of our time debugging
application code rather than debugging niggling issues with PHP/HTML.
-----Original Message-----
From: Tim Olsen [mailto:[EMAIL PROTECTED]]
Sent: 17 July 2001 19:07
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PHP] passing variables from forms to the same page
repetatively
Yeah, I had thought about using hidden inputs, but hidden inputs are not
really hidden. They still exist on the HTML page, and although not visible
in the browser, are visible in the code. This may not be cool if you have
sensitive information that is passed, also if you have a lot of variables to
pass, thats just a lot of hidden inputs to pass.
Is there no other way to accomplish this? No built in function? I guess it
makes sense that there is not, b/c the form submits the form and only the
form variables. Thanks.
-Tim
----Original Message Follows----
From: David Robley <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: "Tim Olsen" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [PHP] passing variables from forms to the same page
repetatively
Date: Tue, 17 Jul 2001 16:13:41 +0930
On Tue, 17 Jul 2001 15:41, Tim Olsen wrote:
> People,
> I have 4 forms in four seperate html pages included directly (no links
> to includes) in the same .php file, i have it so all the form actions
> is php.self, so when each form is submitted it goes on to display the
> next form in line, using if and else statements, of course. I want to
> be able to use variables created by the first form in the html part of
> the last form. What is the best way to do this?
>
> So far, I can only use variables on the next page (form) that is
> written out. After that those variables have no value. Is there some
> way to submit all variables present and assigned with the submission of
> each form? If I make the forms a seperate include file, instead of
> having them in-line, how does this change the ways variables are passed
> or submitted by each form? Thanks, - Tim
> _________________________________________________________________
If I understand what you are saying: those variables don't exist until
you SUBMIT the form. You can demonstrate this by looping through and
displaying your POST or GET vars at the beginning of the form and see
what happens when you first open the page, and when it calls itself.
And re-reading, I think what you may want is hidden fields. You want part
one to call part 2, and retain values from part 1, etc? Echo the values
into hidden fields in each step of the process.
<INPUT TYPE=hidden NAME=whatever VALUE="<?php echo $whatever ?>">
--
David Robley Techno-JoaT, Web Maintainer, Mail List Admin, etc
CENTRE FOR INJURY STUDIES Flinders University, SOUTH AUSTRALIA
I always lie. In fact, I'm lying to you right now!
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
