"Jeffrey W. Baker" wrote:
> 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.
>
I agree with this statement completely.
>
> 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
That is reasonable. In fact, you are not the only one who thinks this way.
For those of you out there who are cross-language developers, Java servlets
provides a similar mechanism.
Servlets can dispatch to other servlets within the same web server-- basically
allowing java data structures to be shared amongst servlets (ie handlers) that
can sandwich each other. Furthermore, the end result can easily dispatch to
JSPs. Thus, you can have a servlet that controls the logical flow through the
program and dispatches to the JSP handler for a particular JSP page. Thus,
your web designers can still use their DreamWeaver's and FrontPage's whilst
you can focus on creating the logic in the core language.
I am not saying this to promote Java, but rather to provide evidence that
there are others that think the way you do even in the other language
communities.
Later,
Gunther
