Multi phase processing

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

Re: Multi phase processing

Dave schrieb:
> 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?

As you're asking for the "best way", I'd suggest you get rid of
the archaic "haul-all-params-ever-entered-with-me-around-hidden"
approach completely and use a decent session module that lets you
store intermediate results with a simple assignment, storing
everything in one go in the database and fetching it on session
initialization. This way, you only need one value (session id)
on the client side to keep track of everything.

An intuitive approach is the CGI::Session module, which already
comes with a mysql backend. Its use is quite similar to the
CGI module itself, so the learning curve isn't steep, and a
tutorial is also included. Even more concise in its usage is
Apache::Session, which lets you tie() your session storage to
a hash.

-Chris

Re: Multi phase processing

Dave wrote:

> 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
^^^^^^
^^^^^^
No it doesn't.

> input tags, and then read back in each time.


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


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

Re: Multi phase processing

Dave wrote:
>
> 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.

Re: Multi phase processing

Tad McClellan wrote:
> Dave wrote:
>
> > 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
> ^^^^^^
> ^^^^^^
> No it doesn't.
>
> > input tags, and then read back in each time.
>
> 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.