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

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

Expand Messages
  • 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 1 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.