1. Reverse proxy, hiding the internal structure from the outside world.
2. HTTP to HTTPs redirection.
3. SSL accellerator.
4. Reverse proxy on the corporate network/operations boundary.
5. Level 4 load balancing switch.
6. Siteminder URL access check.
7. Apache/Tomcat front-end, portal to several applications. (This layer did the presentation).
8. Websphere with *application* business logic (2 databases here: one for the application, one for websphere).
9. "Common", set of Java classes and a database for *bank* business logic.
10. Messages system, layer between the application database and SWIFT routers.
11. SWIFT routers.

Abigail

First of all, three-layer or two-layer architecture are not invented by me, I just utilized them, and they are actually common topic today. There are lots of tools to support both of them. 11-layer architecture does not sound familiar to me ;-)

When you cutting something into layers, there is always a question of how and where to cut. Each layer of your 11 layers actually falls in one of my three layer. A good way to define layer boundaries has to be helpful and can be easily used to describe and understand the system and architecture.

I disagree with your negative evaluation of Abigail's post.

He provided a great example of a mess. His "11-layer" architecture lacks the unified interface shown to the application/display layer, which makes your design work and the "11-layer" cake a pain.

Plus I thought the last line was kind of funny.

I've been using Template Toolkit for display logic, encoding business logic with Class::DBI and subclassing an Apache handler I wrote to tie the two together.

This works incredibly well, as I find my application code running about 1/3 the size of my previous efforts for the same functionality.

Shout outs to Randal Schwartz for advocating Template Toolkit over HTML::Template, and Perrin Harkins for some feedback over on the Template Users mailing list.

Shout outs to Randal Schwartz for advocating Template Toolkit over HTML::Template,

1. Your post reinforces what pg said in his preamble that most people are developing in 2 layers. I myself am doing the same thing right now for a gaming site whose max users will be around 50. I think what pg is saying is that more complex sites require more layers if they are to be understood and maintained.
2. Can you itemize a specific list of advantages that Template Toolkit has over HTML::Template? I would really be interested in seeing such a list. Because for me they are both similar: in-line mini-languages completely at odds with the HTML::Seamstress approach.

CGI::Application rocks the house

princepawn sez:

1. Your post reinforces what pg said in his preamble that most people are developing in 2 layers. I myself am doing the same thing right now for a gaming site whose max users will be around 50. I think what pg is saying is that more complex sites require more layers if they are to be understood and maintained.

Geez, I thought I was developing in 3 layers:

1. Business Logic
2. Display Logic
3. Application Logic

What I got out of pg's post is that he split his business logic into domain specific chunks and then presented a unified interface for those different chunks to his application and display layers.

Given that several different systems embody his business rules, I find his design approach totally appropriate.

2. Can you itemize a specific list of advantages that Template Toolkit has over HTML::Template? I would really be interested in seeing such a list. Because for me they are both similar: in-line mini-languages completely at odds with the HTML::Seamstress approach.

Full support (so far as I know) for Perl objects makes the biggest difference for me. I can pass Class::DBI objects to a template, call a method on it that returns a list and iterate over the list. With HTML::Template, I have to do that in in Perl along with the application logic. I nearly always end up dividing my code somehow into an application side (does work) and a display side (creates HTML). When my template changes, the display code changes. And though I have written display code that can drive any template I throw at it, I never found a clean way to do that.

I like Plugins. When I use a particular set of options (example. all the US states or all the countries in the world) for a select widget over and over again, I set up a singleton plugin object that returns a list of the options and pass the plugin along with the current value of the parameter to a standard template I made that builds HTML selects, for instance.

  [% USE us_states = US_States %]
  [% PROCESS include/select_tag options = us_states, value =  contact.
+us_state %]
[download]

I can use Filters to mutate my output. For instance I could build a PerlTidy filter (sounds obvious to me, I think one already exists), so that my application could clean up random perl code.

  [% USE PerlTidy %]
  [% snippet.perl_code() FILTER PerlTidy %]
[download]

In general, TT handles everything I throw at it in terms of display logic, so my application code stays focused.

. . . for me they are both similar: in-line mini-languages . . .

They are both in-line, but HTML::Template takes the view that HTML designers are not programmers, nor should they be. As such, the only control a template writer has over the output is simple conditionals, loops, and variables. Ignoring, of course, HTML::Template::Expr, which hasn't been updated for over a year, is rather inefficient, and is generally considered an evil step-brother of HTML::Template.

OTOH, TT is practically a full-fledged language of its own.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

The architecture described there is different from what pg seems to be talking about. My interpretation is that pg is splitting the model into data objects and actions that use them, with a thin control layer that maps web requests to actions. That's how Struts works. When we designed the eToys site, we didn't think that was a very valuable distinction, so we had all of the "action" logic inside of mod_perl handlers that were also controllers.

The downside of how we did it is that you would not have been able to call one of those actions from a cron job or other command-line script in any easy way, although you could certainly call the data objects. In a project I just finished working on, we used CGI::Application, and it is possible to use CGI::Application run-modes as "action" objects to some degree. They can be called from test scripts fairly easilly, although you have to pass your params through a CGI object.

As Abigail mentioned, this isn't really a new technique, but it is one that you are drawn to as your system becomes more complex. We had this architecture at eCircles back in 1998, and we're using it now at another site where I'm active, and for exactly the same reasons that you mention. I'll add that decoupling the front-end from the database in this way makes applying changes, and tuning the database (and the queries) a lot easier.

Michael