Is it a trend to use presentation layer to control the business logic?

The answer is NO. This is because:

• Even if this is a trend, this is then just one of the two trends (viewing from a particular perspective). One trend is called thin client, and the other is called thick client. The trend you talked about is thick client, which means the client side does lots of work (too much ?-). Now this makes your client more like a desktop application, and tend to enjoy less benefits provided by the web-based application architecture.
• From a high level design view, business logic is an entity clearly seperated from your presentation layer. 99% of the time, your business logic for each single procedure, could potentially involve many clients (other than that 1% of those most simple business logic). To tightly bundle them with presentation layer makes no sense. I view it as a failure to mix up major components of your application, and believe that it would seriously damage the potential growth of your application. Going the wrong way is fatal ;-)

I've talked about this a bit with Rob Nagler (of Bivio) on the mod_perl list. I really don't agree that the quoted line from the JSP page constitutes business logic. It's a user interface. I also don't think there's any shame in taking the user interface as a starting point to determine the model. The UI is really important, and a UI design often ends up capturing important functionality issues that were not obvious in the abstract.

What Bivio has done is create a presentation abtraction layer. They provide some data with loose instructions on how it should be displayed, and their presentation system turns that into HTML. It puts the "HTML brain" inside of some Perl code that knows how to take instructions like "Grid" and "pad => 0" and turn them into HTML.

This is not a practical solution for the majority of web projects. The design is typically not done by the programmers, and needs to be changeable by people who are not programmers. The Bivio approach doesn't accomplish these goals. I think that one reason it worked so well for them is that they are doing sites that are not very graphically rich. Take a look at http://bivio.com, the investment site they did. It's heavy on functionality, and has a very simple design.

You might be a curmudgeon like me, who wishes more sites looked like Yahoo and worked on Lynx, but being a developer for modern on-line businesses means finding ways to accomodate sites with fairly heavy graphic design elements. Tools like templating modules have done this pretty well, and will probably fit more people's needs than an abstract layout system that generates HTML.

HTML::Template is (intentionally) not capable of embedding Perl.

to the contrary: HTML::Template::Expr

DBSchema::Sample

That only supports specific functions that you add, not actual in-line Perl. At least that's my understanding.

This is not a practical solution for the majority of web projects.

I don't know about majorities, but I do know about applications. bOP doesn't preclude using another templating mechanism. One solution we have used is to let the graphics folks generate their pages however they like. Once they get a design they like, we have them tag programmatically controlled elements, such as, "Login" or "Logout" or nav bars. We also have relied on style sheets to control thematic elements within the app.

I think it is important to address the issue of what controls the application. Most templating languages ignore this. Starting with the UI from a design perspective is fine. That's how we start most projects, and we build dummy models that load fake data. This allows us to prototype the workflow easily, and then we can fill in the business logic without changing the UI. BUT, what we don't do is let the UI guide the control flow. Our applications are task-centric, not page-centric (like JSP and many other toolkits). The advantage is that we can share business and presentation logic in interesting ways. You see an example of this in the petshop.bivio.biz where we reuse the logic for creating/editing accounts.

BTW, visit www.paintedsnapshot.com for an example of a graphics rich site that uses bOP. The artist and programmer were one in the same. The application was developed in a couple of weeks.

The artist and programmer were one in the same.

In most commercial projects, this isn't the case. That's where templating is really useful.

Even JSP does not require you to do things in a page-centric way. The most popular way to use it is from Struts, which is all about defining the controller/model interaction and just using the JSP pages as templates for views.

I think we can create a spectrum of web application solutions in Perl:

Another important category is XML/XSLT-centric transform pipelines, like AxKit.

I don't know where Text::Template categorizes.

It uses embedded Perl expressions (but doesn't provide any flow control blocks). It's a generic templating system, not web specific.

There are also dozens more templating systems on CPAN, although I certainly wouldn't call most of them "web application solutions"...

This tends to be most useful as if you do put anything other than a few variables an html in templates designers tend to break it/not understannd it/mash it with a graphical html editor. with html I think there are 2 real life approaches

1. You give them(designers) very basic templates to add their graphics and html to.
2. They give you a design and you plug it in (more work for programmer but less chance of having to fix things)

Generally if you mix code and html it's a lot harder for the designer than if you give them a template.

2006-06-21 Retitled by holli, as per Monastery guidelines
Original title: 'Separation'

Because templating systems are meant to remove all application/business logic and just focus on the appearance and presentation.

But this is kind of a Bauhaus thing. Remember: form follows function (Bauhaus was some sort of German art institute... not to mention a pretty cool new wave band:)

If you accept input > 25 characters, then you are providing a value which does not mesh with the database constraints... there need to be front end checks to ensure that bad data is never presented to the backend.

DBSchema::Sample

That's certainly true, but at the risk of getting off-topic, you'd be... living dangerously, let's say... to trust the form to check your data integrity. So you're likely going to be checking it server side anyway.

Personally, I like to see that included in forms, not for any application logic or dubious security reasons, but for the general level of ill will you'll generate by silently and ruthlessly obliterating the input from valid users. Preventing such behavior strikes me as a goal of both the presentation and business logics anyway.

If you accept input > 25 characters, then you are providing a value which does not mesh with the database constraints... there need to be front end checks to ensure that bad data is never presented to the backend.

Exactly. Apps built with bOP only get constraint violations for non-uniqueness or exists. Other constraint violations indicate a bug in the application.

The form field meta data is used in two ways: client side validation and server side validation. We never trust what the client sends us, but we try to give as much feedback as is reasonable (without resorting to JavaScript). That's what the maxsize argument is about. You know it, so might as well encode the HTML with it.

Because templating systems are meant to remove all application/business logic and just focus on the appearance and presentation.
I disagree. While most business logic is contained elsewhere, there is still some logic in the presentation layer of the web application I am currently working on. It's along the lines of "If the current user has the privileges to do 'X', show the following link".
The graphic artist types don't need to concern themselves with any of that logic (if there were any on this project); they just need to know that the condition may be true, in which case a link may appear on the page.
--t. alex
Life is short: get busy!

The graphic artist types don't need to concern themselves with any of that logic (if there were any on this project); they just need to know that the condition may be true, in which case a link may appear on the page.

I agree, I think. This turns out to be tricky. Consider the following page:

A | B | C
[download]

where A, B, and C are conditional links, and the vertical bars are visual separators. It's actually tricky to code this in HTML where A might exist, but B might not, and C might. Or for some other arbitrary combination. We usually encode this in a widget, which tests whether A, B, or C are rendered (see below), and then fills in with a separator. In bOP, it might look like:

NavBar(' | ', ['TASK_A', 'TASK_B', 'TASK_C']);
[download]

The NavBar widget's render function would looks something like this (not tested :-):

sub render {
    my($self, $source, $buffer) = @_;
    my($sep) = $self->render_attribute('separator'. $source);
    my($need_sep) = 0;
    foreach my $w (@{$self->get('values')}) {
        my($b);
        $self->unsafe_render_value($w, $source, \$b);
        $$buffer .= ($need_sep++ ? $sep : '') . $$b
            if $$b;
    }
    return;
}
[download]

This delegates the task of knowing how TASK_* is rendered to the widgets that know how to render tasks. In this case, it would be the Link() widget which looks up the permissions and the label based on the task name dynamically.

The question I have is how would this look in other template languages. And, where do the labels come from? How are permissions determined? Who evaluates if the current user's role and the role's authorized permissions.

That's where the "graphic designer" model breaks down. Either the designer has to know Perl to deal with the missing element problem, or the programmer has to work with the designer. There's no simple solution, but if the templating language doesn't offer ways to ask those questions (and most don't in my experience), you are left making things up as you go. That makes for funky websites where links lead to errors as opposed to using the meta data to ensure links don't get rendered unless you have the permission to execute them.

The control decides the operations to perform, what template to show, and gathers the data to fill in the template. The template just presents the data and does not change the state of the system. The template might do some reading from the database but it shouldn't make changes.

an occasionally posting monk from a fellow religion: I work with all kinds of web programming languages and have noted the same kind of inversion of who controls what. Most often there is no controller at all, control flow is implicit.

So recently I stumbled upon several things - will cite them without commentary for the interested reader/coder:

• Java Struts has an XML based Controller that is essentially event based (like .NET based code)
• Cocoon Flow has a controller written entirely in javascript and capturing all the interaction with the client. Disadvantage: All the ballast of Cocoon.
• Chris double comments on continuation based web servers and is implementing one in Scheme (might be wrong). Here's the pointer folks: http://radio.weblogs.com/0102385/
• Last but not least: Here's a pointer to a phd thesis on web interactions. Handles a whole lot more than just continuations: http://www.ccs.neu.edu/scheme/pubs/thesis-graunke.pdf

Sorry for no links, just a copy paste away. Hope to have helped some of you onto this interesting topic.