On Tue, 4 Apr 2000, B&T wrote:

> I've generally created a cgi script per page.  Is that a mistake?
> (I embed the perl in my html so I can edit pages with an html editor)
> 
> I need a better technique for invoking traversals to other pages.
> Right now all I can do is a redirect (internal or external).
> How do you organize things so that from within a script you can either
> display the associated page or invoke any other page/script instead?
> 
>     - just do redirects?
>     - put all page generation in subroutines in one big .pm?
>     - something else (I hope)?
> 
> 
> Example:  My main "home" page has links to "login" and "register"
> scripts/pages, both of which eventually lead to a "user" page.
> With no parameters the login script displays an empty login form.
> Called with get/post parameters it processes the form data;
> on failure it redisplays the login form with a warning,
> on success it should take you to the "user" page (my problem).
> How would YOU organize this?

The way I accomplish this is to divorce the HTML display code from the
application logic as much as possible.  On the web, once you've started
your output, you must complete it.  In order to be able to jump to some
other functionality, you must not start your output until the last
moment.  Thus it is not good to have markup and code mixed together.

Suppose you have an application that has a login page, one page with a
form, and one page that is used to report general errors.  Your handler
might call an authentication method.  Based on the return value, the
handler will call either the login method or the method that spits out the
form.  Either of those methods might return an error, so the handler
checks the return value and invokes the error handler if necessary.  In
any case, the various methods do not actually send anything over the wire,
they simply stash the output away in the request record's notes table.  
The handler is responsible for setting up the response when everything has
run.

You can see that this design is pretty obvious.  The handler is
orchestrating a basic flow of events, and the methods that it invokes are
free to invoke any other method if they wish.  This allows you to
essentially do an internal redirect without the redirect part :)

That's how I do it, for better or worse.
-jwb

Reply via email to