Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > LAMP - Program Design with Perl

Reply
Thread Tools

LAMP - Program Design with Perl

 
 
Dieter
Guest
Posts: n/a
 
      07-11-2004
Hi,

here I'd like to ask for your advice how to
generally code a certain task, not for the details.

O.K.- I try to express myself clearly:

* There's a HTML-form from which the user can choose
many different options (about 15) simultanously in
all possible combinations for a variable number of items
(batch mode).

So e.g. lets say, she can enter "apple, peach, cherry"
and request "color, taste, shape, short description"
out of a set of many other options.

* The CGI-script constructs a statement, depending on the desired
information and queries the MySQL database.

* Depending on what kind of information was requested,
the output from the database is formatted differentially
(headers, linebreaks ... ) and sent to the user.


Now, the system already runs fine just for a few options.
But with a about 15 options in different combinations
I don't want to end up with endless numbers of "if"-clauses.

Do you know a elegant solution, how to manage all the
different optional parameters ?

The problem appears on three stages:

* Parsing the POST data (request)
* Constructing the query for the database
* Handling the output


Maybe there are Perl modules to faciliate this kind of task ?


Dieter
 
Reply With Quote
 
 
 
 
Anno Siegel
Guest
Posts: n/a
 
      07-11-2004
Dieter <(E-Mail Removed)> wrote in comp.lang.perl.misc:

[...]

> Now, the system already runs fine just for a few options.
> But with a about 15 options in different combinations
> I don't want to end up with endless numbers of "if"-clauses.


Time for a timeless quote: "I don't know what your problem is,
but I suggest using a hash"

Seriously, if a cascade of if/elsif spins out of control, a hash is
often the solution.

> Do you know a elegant solution, how to manage all the
> different optional parameters ?


Consider a hash along these lines:

my %options = (
apple => [ qw( size color taste) ],
car => [ qw( size color seats fuel) ],
# ...
);

Note that a hash can also contain code to deal with specific situations.
Such a thing is called a dispatch table, and it is a very powerful tool.

Instead of writing

if ( $thing eq 'apple' ) {
# code to deal with apple
} elsif ( $thing eq 'car' ) {
# code to deal with car
} elsif ( ... ) {

you can construct a hash

my %action = (
apple => sub {
# code to deal with apple
},
car => sub {
# code to deal with car
},
# ...
);

and replace the entire if/elsif construct with

$action{ $thing}->();

Using hashes along these lines is one of the standard techniques in Perl
to deal with complex branching based on string values. It is very
maintainable when options (possible string values) are added, removed
or changed.

Anno
 
Reply With Quote
 
 
 
 
Dieter
Guest
Posts: n/a
 
      07-11-2004
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Anno Siegel) wrote in message news:<ccrg0d$hlh$(E-Mail Removed)-Berlin.DE>...

Yes, I think this is going to the right direction.
The whole thing could be wrapped by "foreach" (see below).

It's not so easy to explain, but my main problem is
that I have to dynamically generate Meta-Information.
Since I don't know what kind of Information the user requests,
it has to be stored somewhere that the e.g. second column returned
from the database is 'color' and not 'size' or 'shape' .

Maybe I do it that way: slurp all parameters from the user
into a hash and then go through all possible parameters
with "foreach" and "if defined".

Maybe the trick is to name the parameters in the HTML-form
exactly the same as they are named in the database and store
the database information in an hash of hashes.


Thanks, Dieter


> Instead of writing
>
> if ( $thing eq 'apple' ) {
> # code to deal with apple
> } elsif ( $thing eq 'car' ) {
> # code to deal with car
> } elsif ( ... ) {
>
> you can construct a hash
>
> my %action = (
> apple => sub {
> # code to deal with apple
> },
> car => sub {
> # code to deal with car
> },
> # ...
> );
>
> and replace the entire if/elsif construct with
>
> $action{ $thing}->();

 
Reply With Quote
 
Anno Siegel
Guest
Posts: n/a
 
      07-11-2004
Dieter <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> (E-Mail Removed)-berlin.de (Anno Siegel) wrote in message
> news:<ccrg0d$hlh$(E-Mail Removed)-Berlin.DE>...
>
> Yes, I think this is going to the right direction.


What is? Please provide context. I have moved the rest of your reply
to the bottom. Please follow the preferred posting style.

> > Instead of writing
> >
> > if ( $thing eq 'apple' ) {
> > # code to deal with apple
> > } elsif ( $thing eq 'car' ) {
> > # code to deal with car
> > } elsif ( ... ) {
> >
> > you can construct a hash
> >
> > my %action = (
> > apple => sub {
> > # code to deal with apple
> > },
> > car => sub {
> > # code to deal with car
> > },
> > # ...
> > );
> >
> > and replace the entire if/elsif construct with
> >
> > $action{ $thing}->();



> The whole thing could be wrapped by "foreach" (see below).
>
> It's not so easy to explain, but my main problem is
> that I have to dynamically generate Meta-Information.


If you find it hard to explain, you have not fully understood your
problem yet.

> Since I don't know what kind of Information the user requests,
> it has to be stored somewhere that the e.g. second column returned
> from the database is 'color' and not 'size' or 'shape' .


Does that mean that the second column of the database stores all
three types of data, and you must know from somewhere else what
it is?

Or are we talking multiple databases, each a key-value mapping
as in tied hashes? It's hard to comment unless you define your
terms more clearly. Or something else?

> Maybe I do it that way: slurp all parameters from the user
> into a hash and then go through all possible parameters
> with "foreach" and "if defined".


No comment on that either, unless you say what you mean by "parameter"

> Maybe the trick is to name the parameters in the HTML-form
> exactly the same as they are named in the database and store
> the database information in an hash of hashes.


That sounds distinctly like a bad idea. Don't tie data together that
underlie independent constraints. (Column-) names in a data base have
one syntax, parameter names in HTML-forms have another. They have
independent life cycles and change for different reasons. Don't force
them together. If those names are user-visible (still not sure what
exactly we're talking about), that's a further no-no.

Instead, it would be a job for a hash to associate user-chooseable
strings with the info needed to access the data base. Another hash
(or the same one) could store the info needed to display the data.
It's hard to be more specific at this point.

Anno
 
Reply With Quote
 
Dieter
Guest
Posts: n/a
 
      07-12-2004
(E-Mail Removed)-berlin.de (Anno Siegel) wrote in message news:<ccs72r$17i$(E-Mail Removed)-Berlin.DE>...

Dear Anno,

thanks for your patience.
It's true that I first have to become clear about the problem.
Maybe it's simpler as I thought. Why not doing this:


%info = cgi -> Vars # What infos about which fruits are needed

#some code for parsing

foreach $fruit (@fruits){
do_this if defined $info{taste};
do_that if defined $info(color)
.....
}

Such a loop could be used for constructing the statement for the
database and also for formatting the output.

As I already said, the problem remains that I have to keep track
what kind of information is returned by the database.
One time the third column could be '"taste", next time it could be
"shape"
or "color". By the way, I didn't mention that the info from the
database
is sucked into an hash of arrays. The fruits are the keys and the
infos
are the values of this HoA. Maybe there's a better way.

Wait a minute, maybe this works also:
Just get the whole row from the DB, and then select the desired
information with the loop described above. Well, that's brute force,
since the rows contain a lot of data.


Best Regards, Dieter


>
> If you find it hard to explain, you have not fully understood your
> problem yet.


That's true, I admit.

> Does that mean that the second column of the database stores all
> three types of data, and you must know from somewhere else what
> it is?


No, each piece of information is stored in its own column.

+cherry+red+sweet+"Cherries are delicious bla+ ...
+lemon+yellow+sour+"Lemon trees bla"+ ...


> Or are we talking multiple databases,


No, definitely not.

>
> > Maybe I do it that way: slurp all parameters from the user
> > into a hash and then go through all possible parameters
> > with "foreach" and "if defined".

>
> No comment on that either, unless you say what you mean by "parameter"


Well, the options chosen from the HTML-form to
be queried from the database.


> > Maybe the trick is to name the parameters in the HTML-form
> > exactly the same as they are named in the database and store
> > the database information in an hash of hashes.

>
> That sounds distinctly like a bad idea. Don't tie data together that
> underlie independent constraints. (Column-) names in a data base have
> one syntax, parameter names in HTML-forms have another. They have
> independent life cycles and change for different reasons. Don't force
> them together. If those names are user-visible (still not sure what
> exactly we're talking about), that's a further no-no.


That's true. Might be a security issue.
 
Reply With Quote
 
Bill
Guest
Posts: n/a
 
      07-12-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Dieter) wrote in message news:<(E-Mail Removed). com>...
> (E-Mail Removed)-berlin.de (Anno Siegel) wrote in message news:<ccs72r$17i$(E-Mail Removed)-Berlin.DE>...
>
> >
> > That sounds distinctly like a bad idea. Don't tie data together that
> > underlie independent constraints. (Column-) names in a data base have
> > one syntax, parameter names in HTML-forms have another. They have
> > independent life cycles and change for different reasons. Don't force
> > them together. If those names are user-visible (still not sure what
> > exactly we're talking about), that's a further no-no.

>
> That's true. Might be a security issue.


To give an example, do not think that the values given in your form
are the only ones that any user may submit. If the allowable colors
for a widget are blue and red, what if the user alters the CGI form to
submit a request for a white widget, and the database generates an
order for one on the back end?

You probably need a database table of valid values (a metadata
database). The CGI should validate data against this prior to changing
the database itself.
 
Reply With Quote
 
Dieter
Guest
Posts: n/a
 
      07-12-2004
Anno,

what do you think about "Tie:BI" ?
Seems to be an interesting module.
Though one has to take significant
decrease of performance into account.


Dieter
 
Reply With Quote
 
Dieter
Guest
Posts: n/a
 
      07-12-2004
Anno,

what do you think about "Tie:BI" ?
Seems to be an interesting module.
Though one has to take significant
decrease of performance into account.


Dieter
 
Reply With Quote
 
Tad McClellan
Guest
Posts: n/a
 
      07-12-2004
Bill <(E-Mail Removed)> wrote:


> To give an example, do not think that the values given in your form
> are the only ones that any user may submit. If the allowable colors
> for a widget are blue and red, what if the user alters the CGI form to

^^^^^^^^^^^^^^^^^^^
> submit a request for a white widget, and the database generates an
> order for one on the back end?



The user does not need to modify the form to submit a request
for a white widget.

The request may not come from a "browser" at all.

An HTTP request is an HTTP request without regard to what kind of
program it was that generated the request.


--
Tad McClellan SGML consulting
(E-Mail Removed) Perl programming
Fort Worth, Texas
 
Reply With Quote
 
Bill
Guest
Posts: n/a
 
      07-13-2004
Tad McClellan <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>.. .
> Bill <(E-Mail Removed)> wrote:
>
>
> > To give an example, do not think that the values given in your form
> > are the only ones that any user may submit. If the allowable colors
> > for a widget are blue and red, what if the user alters the CGI form to

> ^^^^^^^^^^^^^^^^^^^
> > submit a request for a white widget, and the database generates an
> > order for one on the back end?

>
>
> The user does not need to modify the form to submit a request
> for a white widget.
>
> The request may not come from a "browser" at all.
>
> An HTTP request is an HTTP request without regard to what kind of
> program it was that generated the request.


All true, and irrelevant to the discussion?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Perl + LAMP / PHP JOB jon.kay@mayfieldcurzon.com Perl Misc 2 11-09-2007 11:51 PM
HP Photosmart 2610 lamp control?... s_powelson Computer Support 1 08-02-2005 04:55 PM
LAMP & J2EE as opposed to LAMP vs J2EE Ross M. Greenberg Java 6 12-24-2004 09:59 PM
Agfa Snapscan scanner lamp P and H Macguire Digital Photography 5 02-09-2004 08:57 AM
Canon S230 Focus Assist lamp Richard Digital Photography 3 01-02-2004 11:53 PM



Advertisments