[RDF] Re: [Templates] which strategy for building TT apps under mod_perl?

Jonas Liljegren jonas@liljegren.org
21 Dec 2000 11:03:31 +0100


Vivek Khera <khera@kciLink.com> writes:

> Has anyone built apps both ways and found one to be significantly
> better for development and/or performance?


I have done systems there the pages are static but generated from a
database.  For those systems, I have created a administration system
using templates for the administration pages. After a change, the
program will use other templates to regenerate the changed static
pages.


I am also using a combination of control from program and template
(pipe and callback).  A requst from the browser, based on the
presently viewed page, will have two parts: ACTION and VIEW.

   ACTION is things that changes things.  This is usually updates of
   the database or creation of a file or something else.

   VIEW holds the requested information.  This is a description of
   what the client want to see.  Typically it's a combination of a
   template and an object identifier and things like sort order and
   more.

The request is handled in these two stages.  First we process the
ACTIONs.  These actions can either completely succeed or they can
partly succeed or fail.  

The ACTION results decides which template to call.  The VIEW template
will be called if all goes well.  But incorrect input or a failed
database update will result in that the previous template will be
called again, with the previous input as default values.


The logical extension of this is to have a PLAN.  I think that this is
the right way for operations that takes several steps and that can
branch out depending on the choices made.  Example:

1. The goal is to create a person description page (and then view it).
   The creation page includes a list of projects the person works
   with, selectable from a listbox.  You see that the project has not
   yet been entered and klick the button for adding a new project.

2. The partly filled form is submitted as an ACTION and the PLAN is to
   continue editing it.  But first, we will VIEW the project creation
   page.  The project involves a certain customer.  But that customer
   has not yet been entered into the database.  (Or maby the customer
   is there but some information about them needs updating.)

3. You klick to add the customer. The ACTION is to save this partly
   entered project.  The task to continue editing the project is
   prepended to the PLAN.  You add the customer.  Then you are done,
   the customer data will be comitted to the database. (Or it will be
   activated with a boolean or activation date or version number or
   something.)  Since no VIEW was explicitly given, the VIEW will be
   determined by shifting the last added value from the PLAN.


-- 
/ Jonas  -  http://jonas.liljegren.org/myself/en/index.html