Multi phase processing

[Dave]

Hi folks,

I writing a perl/mysql backend to a website, part of which takes a
number of pages of input, then, at the end, stores all the info on the
database. Since Apache is stateless, all the data input from previous
pages has to be put back into the next page in the form of hidden
input tags, and then read back in each time. This is a touch long
winded, but for most of the data works fine. I have however hit a snag
with 1 set of data that is made up of a repeating set of which any
number (or none) may be selected.

This data is a set of dynamically generated tick boxes of related
data, all of which is taken from some data tables on the database. For
example, if the page was asking which languages a person programmes
in, it would then offer a list of choices from the database which the
end user selects from. Part of the problem is that it also lists 3
separate options against each, for example used on VME, Windows,
Linux.

The end result would look something like this, where each '@' is a
separate input type="checkbox" html tag:

Language VME Windows Linux
Application Master @ @ @
C @ @ @
Cobol @ @ @
Perl @ @ @
SCL @ @ @

The idea being that if someone has programmed in Cobol on VM, and in
Perl on Windows and Linux the appropriate boxes are ticked. The
validation is fun because in the above, cut down, example, Application
master and SCL are only available on VME, and Perl is the only one not
available on VME. The other two being available on all platforms.

Where this is the only page, so that all the info is input in one go,
I have no problems. Where I have a problem, is holding this in
temporary input type = "hidden" tags within the html page. Does anyone
have any suggestions on the best way to hold this data?

I hope all this makes sense.

Many thanks,

Dave

 

[xhoster]

The end result would look something like this, where each '@' is a
separate input type="checkbox" html tag:

Language VME Windows Linux
Application Master @ @ @
C @ @ @
Cobol @ @ @
Perl @ @ @
SCL @ @ @

The idea being that if someone has programmed in Cobol on VM, and in
Perl on Windows and Linux the appropriate boxes are ticked. The
validation is fun because in the above, cut down, example, Application
master and SCL are only available on VME, and Perl is the only one not
available on VME. The other two being available on all platforms.

I'm not sure why any peculiar type validation is needed. You have no way
to prevent people from lying, do you? If not, why take pains to make
sure their lies are at least plausible?

Where this is the only page, so that all the info is input in one go,
I have no problems. Where I have a problem, is holding this in
temporary input type = "hidden" tags within the html page. Does anyone
have any suggestions on the best way to hold this data?

I don't understand the problem. You should be able to stuff it back
into hidden tags exactly the same way you get it out of the original
submission. For example, if all the checkbox names start with "lang_exp",
like "lang_exp_C_VME", "lang_exp_Perl_Linux", then something like:

print $q->hidden($_) foreach grep /^lang_exp/, $q->param();

Should work, right?

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[xhoster]

^^^^^^
^^^^^^
No it doesn't.


Passing via hidden fields is but 1 of 3 "usual" ways of managing state,
and it is generally the worst of the three.

The 3 usual ways, in order of "best to worst" are:

store info on server and pass only a session ID around

store info in cookies

store info in hidden fields

Why are cookies better than hidden fields? I usually find hidden fields
much better than cookies. In fact, I often find them better than sessions.
It doesn't really require any extra flap-doodle, as I need to collect and
validate the data in the first place, I can use the same code to do it
again out of the hidden field. I don't need to install some special module
to keep state and then maintain and configure it. If the server crashes
momentarily, the user hasn't lost their state. I don't have to decide how
long to maintain state for people who are taking a long time to finish all
the steps of the task.



Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[John Bokma]

Okay thanks, I'll have a look at these. I know I'll be able to install
the, on my own dev server, but I may not have that luxurie on the live
server.

If you have a shell account, you always can install Perl modules in a
different directory. If you haven't, you might be able to write a CGI
script that installs a Perl module in a directory you've access to ;-)

 

[Ben Morrow]

My problem is that part of the data is dynamically generated, and I
cannot, currently, see an obvious way to drop it into hidden fields. (Or
for that matter cookies!)

You can serialize any Perl data structure with e.g. Storable +
MIME::Base64, or Data:umper, or YAML, and put the result into a single
hidden field. The outcome is rather similar to using a session ID in a
hidden field, except you have to send all the data down to the client
all the time.

Ben