Mailing List Archive

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

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