in reply to the trend of the presentation layer driving application logic

FYI, Text::Template is embedded Perl. HTML::Template is (intentionally) not capable of embedding Perl.

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.

  • Comment on Re: the trend of the presentation layer driving application logic

Replies are listed 'Best First'.
Re: Re: the trend of the presentation layer driving application logic
by princepawn (Parson) on Nov 03, 2003 at 01:49 UTC
      That only supports specific functions that you add, not actual in-line Perl. At least that's my understanding.
Re: Re: the trend of the presentation layer driving application logic
by robnagler (Novice) on Nov 04, 2003 at 21:37 UTC
    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.