From heather38@example.com Wed May 03 15:34:14 2006
Return-Path: <heather38@example.com>
Delivered-To: heather38@example.com
Received: (qmail 49731 invoked from network); 3 May 2006 15:34:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 3 May 2006 15:34:03 -0000
Received: (qmail 5753 invoked by uid 500); 3 May 2006 15:33:36 -0000
Delivered-To: heather38@example.com
Received: (qmail 5602 invoked by uid 500); 3 May 2006 15:33:36 -0000
Mailing-List: contact heather38@example.com; run by ezmlm
Precedence: bulk
list-help: <mailto:heather38@example.com>
list-unsubscribe: <mailto:heather38@example.com>
List-Post: <mailto:heather38@example.com>
List-Id: <asp.perl.apache.org>
Delivered-To: mailing list heather38@example.com
Received: (qmail 5539 invoked by uid 99); 3 May 2006 15:33:35 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 08:33:35 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [83.161.120.155] (HELO web36903.mail.mud.yahoo.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 May 2006 08:33:34 -0700
Received: (qmail 84894 invoked by uid 60001); 3 May 2006 15:32:40 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=6jrwmGjdMkLXiBD2rxs8Js9XVgBg+QQkDQLGXKivYfSPAJBAUGB+rCN4xuLZAIDiIieg+60YWQzDLjcuG34OZuJ2ivYh9PuZ/TfWjgbV90cNG5FZyNGeFEVHWZuEaBAJ0MU7Yg1CSkoIoFydFkfAO15IMjxgFsuWKvsF1+BN/Ko=  ;
Message-ID: <heather38@example.com>
Received: from [83.161.120.155] by web36903.mail.mud.yahoo.com via HTTP; Wed, 03 May 2006 08:32:40 PDT
Date: Wed, 3 May 2006 08:32:40 -0700 (PDT)
From: Steve B <heather38@example.com>
Subject: Cleanly separating applications vs. presentation using Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP
To: heather38@example.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Greetings,

First off, I want to thank John Drago for his
assistance with managing Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP 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 Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP.  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 Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP 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
HTML888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4Template).  However, this "feels" to me to be
somewhat redundant when using Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP 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 Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP 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: heather38@example.com
For additional commands, e-mail: heather38@example.com


From heather38@example.com Wed May 03 18:59:06 2006
Return-Path: <heather38@example.com>
Delivered-To: heather38@example.com
Received: (qmail 76452 invoked from network); 3 May 2006 18:59:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 3 May 2006 18:59:06 -0000
Received: (qmail 90610 invoked by uid 500); 3 May 2006 18:59:05 -0000
Delivered-To: heather38@example.com
Received: (qmail 90551 invoked by uid 500); 3 May 2006 18:59:03 -0000
Mailing-List: contact heather38@example.com; run by ezmlm
Precedence: bulk
list-help: <mailto:heather38@example.com>
list-unsubscribe: <mailto:heather38@example.com>
List-Post: <mailto:heather38@example.com>
List-Id: <asp.perl.apache.org>
Delivered-To: mailing list heather38@example.com
Received: (qmail 90506 invoked by uid 99); 3 May 2006 18:59:03 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 11:59:03 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [83.161.120.155] (HELO web36913.mail.mud.yahoo.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 May 2006 11:59:01 -0700
Received: (qmail 69762 invoked by uid 60001); 3 May 2006 18:58:41 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=scFXf1Y+FzxFaoLYGscP35lzmdSOmLgRLkCQCOk3Bu9iS82t7GB27vrWBektQNgZF7urQmGu8H728iJAig3oY2rWu9dB/JJhmaed2YOtzPxttZ/Ld0K0bayyFaPJ7QQFtmt0bxnI2DHZ0diR0c9gjHkMvWgklEU3dwYzWFiyjmU=  ;
Message-ID: <heather38@example.com>
Received: from [83.161.120.155] by web36913.mail.mud.yahoo.com via HTTP; Wed, 03 May 2006 11:58:40 PDT
Date: Wed, 3 May 2006 11:58:40 -0700 (PDT)
From: Steve B <heather38@example.com>
Subject: RE: Cleanly separating applications vs. presentation using Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP
To: John Drago <heather38@example.com>, heather38@example.com
In-Reply-To: <heather38@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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 = "MyApp888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ontroller888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4" .
$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: heather38@example.com
For additional commands, e-mail: heather38@example.com


From heather38@example.com Wed May 03 21:36:09 2006
Return-Path: <heather38@example.com>
Delivered-To: heather38@example.com
Received: (qmail 87755 invoked from network); 3 May 2006 21:36:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 3 May 2006 21:36:09 -0000
Received: (qmail 60296 invoked by uid 500); 3 May 2006 21:36:08 -0000
Delivered-To: heather38@example.com
Received: (qmail 60201 invoked by uid 500); 3 May 2006 21:36:07 -0000
Mailing-List: contact heather38@example.com; run by ezmlm
Precedence: bulk
list-help: <mailto:heather38@example.com>
list-unsubscribe: <mailto:heather38@example.com>
List-Post: <mailto:heather38@example.com>
List-Id: <asp.perl.apache.org>
Delivered-To: mailing list heather38@example.com
Received: (qmail 60183 invoked by uid 99); 3 May 2006 21:36:07 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 14:36:07 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [83.161.120.155] (HELO etr-usa.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2006 14:36:05 -0700
Received: (qmail 66902 invoked by uid 13447); 3 May 2006 21:35:44 -0000
Received: from unknown (HELO [83.161.120.155]) ([83.161.120.155])
          (envelope-sender <heather38@example.com>)
          by 83.161.120.155 (qmail-ldap-1.03) with SMTP
          for <heather38@example.com>; 3 May 2006 21:35:44 -0000
Message-ID: <heather38@example.com>
Date: Wed, 03 May 2006 15:35:44 -0600
From: Warren Young <heather38@example.com>
User-Agent: Thunderbird 83.161.120.155 (Windows/20060308)
MIME-Version: 1.0
To: Apache-ASP List <heather38@example.com>
Subject: Re: Cleanly separating applications vs. presentation using Apach888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4ASP
References: <heather38@example.com>
In-Reply-To: <heather38@example.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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: heather38@example.com
For additional commands, e-mail: heather38@example.com



{'source': 'Apache Software Foundation Public Mail Archives'}