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

RE: Cleanly separating applications vs. presentation using Apache::ASP

Expand Messages
  • 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 1 of 3 , May 3, 2006
      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 2 of 3 , May 3, 2006
        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.