Cleanly separating applications vs. presentation using Apache::ASP

[Steve B <mo...@yahoo.com>]

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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org

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

[Warren Young <wa...@etr-usa.com>]

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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org