[siesta-dev] [robin@xxxxxxxx.xxx.xx: Re: Siesta web frontend]

[prev] [thread] [next] [lurker] [Date index for 2003/04/30]

From: Richard Clamp
Subject: [siesta-dev] [robin@xxxxxxxx.xxx.xx: Re: Siesta web frontend]
Date: 11:40 on 30 Apr 2003
--Dxnq1zWXvFF0Q93v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Robin sent this to me a while ago and I was planning to
summarise it and just send on the important stuff, but so far I'm the
weakest link.

Here it is in its unedited form to let everyone see and think on it.

-- 
Richard Clamp <richardc@xxxxxxxxx.xxx>

--Dxnq1zWXvFF0Q93v
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <robin@xxxxxxxx.xxx.xx>
X-Original-To: richardc@xxxxxxxxx.xxx
Delivered-To: richardc@xxxxx.xxxxx.xx.xx
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85])
	by mirth.demon.co.uk (Postfix) with ESMTP id 6F8F933FBF
	for <richardc@xxxxxxxxx.xxx>; Thu, 24 Apr 2003 23:58:32 +0100 (BST)
Received: from rszemeti.demon.co.uk ([158.152.98.107] helo=redpoint.org.uk)
	by anchor-post-35.mail.demon.net with esmtp (Exim 3.36 #2)
	id 198pfR-0004Td-0Z
	for richardc@xxxxxxxxx.xxx; Thu, 24 Apr 2003 23:58:14 +0100
Sender: robin@xxxxx.xxxxx.xx.xx
Message-ID: <3EA85382.A32A510F@xxxxxxxx.xxx.xx>
Date: Thu, 24 Apr 2003 22:13:38 +0100
From: Robin Szemeti <robin@xxxxxxxx.xxx.xx>
Organization: Redpoint Consulting Limited
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: en, en-US
MIME-Version: 1.0
To: richardc@xxxxxxxxx.xxx
Subject: Re: Siesta web frontend
References: <3EA85034.D8C1B856@xxxxxxxx.xxx.xx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robin Szemeti wrote:

gah .. sodding netscape ..

> OK .. this is more like a tream of conciousness rather than an plan of
> what I had in mind, because the plan was evolving in my brain before I
> got anywhere near coding it and 2 weeks of other foo have scrubbed what
> little sense I had.
>
> My basic idea was to shift as much code/logic as possible out of
> template space and into perl space.
>
> Looking at Template::Plugin:;Siesta.pm  I had written some boilerplate
> and implemented on small but useful part, register.
>
> register.tt2 you will notice is small and lite.
>
> next on my list was to tweak the Apache::Template config somthing like
>
>   TT2IncludePath      /home/siesta/website/lib
>   TT2IncludePath      /home/siesta/website/source
>   TT2PreProcess       config
>   TT2Process          wrapper.tt2
>   <Files *.html>
>      SetHandler      perl-script
>      PerlHandler     Apache::Template
>   </Files>
>
> and have wrapper.tt2 as the outer wrapper which puts the top, footerm,
> fills out the panels etc.
>
> have somethinkg like:
> <head>

<body>
lots of header html, top of page etc


>
> [% IF require.login AND Siesta.logged_in; PROCESS $template; ELSE;
> PROCESS login_form.tt2; END; %] as the main handler in the wrapper.

process footer.tt2 etc

>
> Then have the various show_subs.tt2  templates set:
>
> [% META require.login = 1 %] or [% require.listAdmin =1 %] or whaterevr
> ..  basically AIUI the template is parsed but not actioned and held as
> template data in $template, but the META tags throw back data into the
> parent namespace, so are ideal for setting
>
> etc, causing the wrapper to either show ot not show the page foo.

this remove all the logic from the pages so it can al live in stuff like
wrapper in ./lib

all the user pages just contain forms and shit, so making them nice and
user friendly for tweaking and stuff by users, without them having to get
involved with IF and ELSE clauses and potentially scrwing up.

the [% PROCESS $template %] should really be wrapped in a [% TRY .. %]
[% CATCH .... %] so it does something sane when a keen template editor
screws up ...

>
>
> the next bit for attention is login and actions once logged in (change
> prefs, sub, unsub, view non-public lists etc.
>
> so :
>
> 1) implement an auth scheme.  Apache::AuthCookie is the baby.
>
> but it also needs some ro^le based methods
>
> 2) implement T::P::S logged_in, is_admin,  etc,
>
> 3) all I wa going to do then was work through the muttley based PHP,
> pushing as much code in T::P::Siesta as possible and keeping each page
> itself as lite as possible, letting the wrapper.tt2 handle as much logic
> as it can.
>
> 4) each method can push errors onto T::P::S->errors.
>
> no wait .. it gets worse. I was going to replace

where was I .. before Nutscrape sent that all on its own ..

ah yes .. I was going to replace the crufty hand coded OO implementation
with Class::Methodmaker, and then you suggested using Class::<foo>::Fast or
something .. and then I went to geneva and forgot all about it. so theres a
good little chunk for someone.

umm this is all boolocks isnt it because Ive forgotten more than I knew ...

so three identifiable chunks are:

port T::P::S to Class::foo::Fast

convert the TT structure to a wrapper like structure, pushing more stuff
out of the files.

implement an auth scheme probably on Apache::AuthCookie or similar ( but
overiding the crazy methods that call login.pl and the <Files /LOGIN> stuff
in apache config is not wanted .. just overide those methods doing sane
things and AuthCookie could be OK ... or maybe something else.)

port muttleys PHP page by page, starting at the most useful ( ie the user
facing pages such as subscribe and unsubscribe, preferences etc ..)

sorry brain dead. too much life has happened to me recently and Ive lost
the thread on this a bit ...

pity .. I was enjoying the bits I did and learning about SVN and stuff too
... ho hum



--Dxnq1zWXvFF0Q93v--

Generated at 13:56 on 01 Jul 2004 by mariachi 0.52