LAMP - Program Design with Perl

Discussion in 'Perl Misc' started by Dieter, Jul 11, 2004.

  1. Dieter

    Dieter Guest

    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
     
    Dieter, Jul 11, 2004
    #1
    1. Advertising

  2. Dieter

    Anno Siegel Guest

    Dieter <> 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
     
    Anno Siegel, Jul 11, 2004
    #2
    1. Advertising

  3. Dieter

    Dieter Guest

    -berlin.de (Anno Siegel) wrote in message news:<ccrg0d$hlh$-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}->();
     
    Dieter, Jul 11, 2004
    #3
  4. Dieter

    Anno Siegel Guest

    Dieter <> wrote in comp.lang.perl.misc:
    > -berlin.de (Anno Siegel) wrote in message
    > news:<ccrg0d$hlh$-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
     
    Anno Siegel, Jul 11, 2004
    #4
  5. Dieter

    Dieter Guest

    -berlin.de (Anno Siegel) wrote in message news:<ccs72r$17i$-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.
     
    Dieter, Jul 12, 2004
    #5
  6. Dieter

    Bill Guest

    (Dieter) wrote in message news:<>...
    > -berlin.de (Anno Siegel) wrote in message news:<ccs72r$17i$-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.
     
    Bill, Jul 12, 2004
    #6
  7. Dieter

    Dieter Guest

    Anno,

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


    Dieter
     
    Dieter, Jul 12, 2004
    #7
  8. Dieter

    Dieter Guest

    Anno,

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


    Dieter
     
    Dieter, Jul 12, 2004
    #8
  9. Bill <> 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
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jul 13, 2004
    #9
  10. Dieter

    Bill Guest

    Tad McClellan <> wrote in message news:<>...
    > Bill <> 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?
     
    Bill, Jul 13, 2004
    #10
  11. Dieter

    ChrisO Guest

    Dieter wrote:
    > 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 ?


    I have to second Anno's suggestion that you look very hard at a
    "dispatch table" setup using a hash. Very powerful stuff. You agreed
    somewhat, but then I saw you spit out some more nested "if" constructs,
    so I think it worthwhile to second Anno's suggestion on this method (eg.
    dispatching).

    Secondly, at the risk of further complicating things for you, if you are
    willing to take the time to thoroughly understand it, an recent article
    by Randal Schwartz may be helpful to you (from _Linux Magazine_, Feb 2004):

    http://www.linux-mag.com/2004-02/perl_01.html

    Also consider in your "web application mix" not only Class::prototype
    (mentioned in Randal's article), but maybe even CGI::Application, and I
    can't even imagine doing a web application without HTML::Template. At
    the very least, HTML::Template can help get your mind off the
    presentation layer and it's "connection" to your logic and allow you to
    just focus on your logic.

    Aside from the hint about dispatch tables, the rest of my suggestions
    require some familiarization with Perl beyond the beginning stages;
    judge for yourself to what level of Perl prowess you would place
    yourself. But the article above could be helpful to you. Certainly
    your discussion reminded me of it.

    -ceo
     
    ChrisO, Jul 17, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ross M. Greenberg

    LAMP & J2EE as opposed to LAMP vs J2EE

    Ross M. Greenberg, Dec 12, 2004, in forum: Java
    Replies:
    6
    Views:
    1,462
    Robert kebernet Cooper
    Dec 24, 2004
  2. Jeremy Bowers

    OT: why are LAMP sites slow?

    Jeremy Bowers, Feb 3, 2005, in forum: Python
    Replies:
    53
    Views:
    1,376
    Almad
    Feb 7, 2005
  3. Santhosh
    Replies:
    0
    Views:
    334
    Santhosh
    Sep 8, 2006
  4. Santhosh
    Replies:
    0
    Views:
    276
    Santhosh
    Sep 8, 2006
  5. Perl + LAMP / PHP JOB

    , Nov 8, 2007, in forum: Perl Misc
    Replies:
    2
    Views:
    94
    David H. Adler
    Nov 9, 2007
Loading...

Share This Page