Loading ...
Sorry, an error occurred while loading the content.

Cleanly separating applications vs. presentation using Apache::ASP

Expand Messages
  • Steve B
    Greetings, First off, I want to thank John Drago for his assistance with managing Apache::ASP sessions external to the environment. My question this time is
    Message 1 of 3 , May 3, 2006
    • 0 Attachment
      Greetings,

      First off, I want to thank John Drago for his
      assistance with managing Apache::ASP sessions external
      to the environment.

      My question this time is more religious/philosophical
      than it is technical. I have inherited a legacy web
      application that runs on Apache::ASP. The application
      was designed in 1998-2000 by developers that weren't
      very familiar with perl. As a result, there are a lot
      of design flaws that need to be worked around. The
      most notable design flaw is the tight integration
      between the application and the display. Perl code
      is directly intermingled with the HTML page, making
      the external management of the page elements nearly
      impossible.

      While I know that this is what Apache::ASP is about
      and sometimes doing the above is desirable, I also
      know that it makes ongoing page maintenance for
      nontrivial sites a nightmare. One possible workaround
      is using a simple perl templating library (such as
      HTML::Template). However, this "feels" to me to be
      somewhat redundant when using Apache::ASP in the first
      place.

      I guess the root of my question is this: how do *you*
      prefer to abstract the application and display
      components in your Apache::ASP applications? Are
      there standard, "accepted" ways of doing this?

      Thank you very much in advance for any tips and
      advice.

      Steve

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com

      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Steve B
      John, Thanks you - I now have a much clearer understanding how to better split business logic and display. I do have one implementation question. In one of
      Message 2 of 3 , May 3, 2006
      • 0 Attachment
        John,

        Thanks you - I now have a much clearer understanding
        how to better split business logic and display. I do
        have one implementation question. In one of your
        examples you cited the following:

        #==================================================
        my $class = "MyApp::controller::" .
        $Request->QueryString('mode');
        my $redir = eval {
        $class->process( $Application, $Session, $Request,
        $Response, $Server
        );
        };
        if( $@ )
        {
        # There was a problem:
        die "Error: $@";
        }
        else
        {
        $Response->Redirect( $redir );
        }# end if()
        #==================================================

        From the context of the example, I assume that you are
        passing display parameters to the redirect script
        through the URL. This works for smaller examples, but
        may not necessarily be the most effective/efficient
        way to do it for a large data set (say, a 30kb text
        field). One workaround I came up with was to use
        Response->Transfer() and load up the @args parameter
        with data. Is there a cleaner way of keeping the data
        "transfer" completely on the server side? Global
        variables would actually work here, but even I
        consider that solution far too ugly to even consider.

        Thanks again!
        Steve

        __________________________________________________
        Do You Yahoo!?
        Tired of spam? Yahoo! Mail has the best spam protection around
        http://mail.yahoo.com

        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      • Warren Young
        ... You re right, there is a lot of religion on this topic. The way I see it, you can t be pure either way. You will always end up with some UI code in your
        Message 3 of 3 , May 3, 2006
        • 0 Attachment
          Steve B wrote:
          >
          > The
          > most notable design flaw is the tight integration
          > between the application and the display. Perl code
          > is directly intermingled with the HTML page, making
          > the external management of the page elements nearly
          > impossible.

          You're right, there is a lot of religion on this topic.

          The way I see it, you can't be "pure" either way. You will always end
          up with some UI code in your application logic, or vice versa. And I
          don't advocate trying to separate them "as much as possible". That
          leads to holy quests, where what is being tested is your purity by the
          standards of the particular priest you're following, not the soundness
          of your design.

          What I do is look for reusable code, and blocks of closely related code,
          and put that into Perl modules. The reusable code bit is obvious: no
          sense duplicating code, right? But I'll also collect together many
          related functions and put them into a class, and make that a Perl
          module. Most of these functions might be called from only one .asp
          file, so it's not a matter of reuse, but it is fair to say that all of
          these functions logically function together, so they should be kept
          together. This makes the most sense when these functions don't have any
          reason to contain any HTML.

          For instance, I have a layer between the database and the UI code in my
          current project, and the code forming that layer is in a single large
          .pm file. They return raw data (hash references, arrays, etc.), which
          the ASP code then renders into a human-usable format.

          The ASP code that calls these functions is a mixture of Perl and HTML:
          it might call a function in the module that returns an array of hash
          references, and use that to build an HTML table containing the data.
          That mixes some Perl code with my UI code, but that's fine. What
          matters is that the meat of the application code is separate from the UI
          code.

          Another rule I have is that .asp files should contain mainly HTML. Code
          sections in other languages -- Perl, JavaScript, etc. -- should never be
          longer than will fit in your programmer's editor window. You should be
          able to see some HTML in the editor window at all times, because that
          helps you to keep your mind focused on the context of the application.
          When you're skipping over great swaths of "foreign" code to see how one
          HTML section works with another, you cannot see this flow. I like to
          keep these sections of code shorter than 10 lines, if I can. These
          snippets of code should be there just to glue pieces together, not to
          contain serious blocks of logic.

          This isn't to say that I'll interrupt a block of, say, 30 lines of Perl
          code to spit out one pure line of HTML, just to divide that block and
          satisfy my previous rule. In that case, I'll often put the HTML into a
          Perl print statement, just to keep the flow of the Perl code going.
          Again, it's about maintaining flow...don't confuse the code's reader by
          switching between languages more than necessary.

          You satisfy all of these rules at once by minimizing the amount of Perl
          code that needs HTML interspersed, and the amount of HTML that needs
          Perl in it.

          I guess what I'm saying is, separation of UI and application code is a
          high-level rule that you do not follow directly. You follow many lower
          level rules that together create this effect, giving the illusion that
          you're following just this one high-level rule. You have to think in
          terms of the low-level rules, because it turns into a matter of
          heuristics: you'll have two or more options, neither of which is wholly
          right or wrong, and you'll have to make some kind of choice between
          them. Making that choice by following the high-level generalized rule
          can lead you into a mess, whereas weighing the many low-level rules
          against each other can make correct the path clear.

          ---------------------------------------------------------------------
          To unsubscribe, e-mail: asp-unsubscribe@...
          For additional commands, e-mail: asp-help@...
        Your message has been successfully submitted and would be delivered to recipients shortly.