Vivek Khera wrote:
> >>>>> "RM" == Robert McArthur <[EMAIL PROTECTED]> writes:
>
> RM> example of the issue, assume the system needs users to login before
> RM> using
> RM> it, and that the login page needs state information in case the user
> RM> started at a particular page, needs to authenticate/join and so comes to
>
> This is *exactly* what Apache::AuthCookie does. I implement it in
> Perl as a handler, but do the redirects to a TT processed document.
> The TT document needs access to the mod_perl Apache->request() object,
> so I wrote a simple plugin for that.
Vivek,
Thanks for the help. I wasn't using AuthCookie but I certainly can
sometimes! Thanks again.
However, I'd still like some feedback/comments from people about
the ideas. Vivek's solution for authentication is good but
a) I'm not going be using Apache all the time, and b) it doesn't
assist me in deciding where to put the 'smarts' for all sorts of
other topics.
For example, suppose I have a DB table with username and lots of
other information. Another table has more info based on a userid
key form the first table. I want to show a simple list of username
and some information about that user.
[% USE DBI %]
[% DBI.connect(dsn, specialuser, secretpass) %]
[% query = DBI.prepare('SELECT * FROM users,other WHERE userid = ?')
%]
[% FOREACH user = query.execute(idUserProvided) %]
[% query.name %]
[% query.emailaddress %]
[% END %]
or I can instantiate in perl and the template becomes
[% user.name %]
[% user.emailaddress %]
The former is easier to modify (for many people) than the perl that the
latter would require. If we wanted to show another attribute that
resides in another linked table - say usersPhoto - then the former
is simple to change in the template, whereas the latter requires mucking
around in the perl. But the "business logic" seperation is nicer in the
latter since the template doesn't have to know anything about the
database structure...
Again, any thoughts?
Robert
