Pondering Portals

hacker has asked for the wisdom of the Perl Monks concerning the following question:

Many of us have started out writing small HTML pages, then transitioned those into SSI, and from there, into Perl, and then embellished those into more-complicated "systems", and probably even larger portal systems.

So then you move to templating systems, HTML::Template, Text::Template, mod_perl, CGI.pm, and combinations of all of the above, to achieve what you want.

I've done the same thing... too many times. Rolling a "portal" from scratch is no fun.

But now I'm at an impasse. I'm going to be (re)writing and fixing my existing "portal" sites, and I need some philosophy and experiences from other fellow monks as to the choices I should be making.

mod_perl is a must, so that can't go away, and these are heavily database and system-tool-driven portalesque sites. Those are immovable requirements. These sites are all VERY heavily-hit, so lean and fast with some modicum of caching is a must, but being able to lower maintenance and upkeep is also heavy on the requirements.

So the question is: Mason? TemplateToolkit? Others? And why?

I've played around with the PHP-based portals and CMS systems such as Drupal, e107, and even the Python-based Zope portals (Plone) as well as dozens of other alternatives but they really weren't flexible enough to be anything more than a "super-blog".

Santa brought me the mod_perl Developer's Cookbook and the Mason O'Reilly book early this year, and I will be digesting those over the next few days to get up to speed with some of the innards of the two.

Should I be looking at others? Any gotchas? Foibles? Kinks in my plan?

Comment on Pondering Portals

Replies are listed 'Best First'.
Re: Pondering Portals by inman (Curate) on Dec 24, 2004 at 10:31 UTC
I have done some work recently using RSS as a means to feed content to a portal. The RSS feeds themselves can come from external sites or be distributed over the multiple servers. A caching RSS server can then be used to limit the impact on the backend systems. For example - a personalised page can contain office news, local weather, my e-mail inbox, News from my favourite feeds etc. These can all be supplied through a caching RSS server with the cache refresh set to different rates. My inbox refreshes every five minutes whereas the news is once every half hour.	[reply]
Re: Pondering Portals by rdfield (Priest) on Dec 24, 2004 at 11:19 UTC
I've recently built a fairly large and complex site using HTML::Mason and can thoroughly recommend it. Reading the book by ~~davorg~~ autarch and kwilliams is a must, but the learning curve isn't especially steep and the speed of development compared to, say, CGI, is an order of magnitude quicker taking bug fixing and general maintenance into account. rdfield	[reply]
Re^2: Pondering Portals by Arunbear (Prior) on Dec 24, 2004 at 15:29 UTC
The Mason book is authored by autarch and kwilliams, not davorg (who is a co-author of the Template Toolkit book).	[reply]
Re: Pondering Portals by steves (Curate) on Dec 24, 2004 at 15:38 UTC
You might want to also check out OpenInteract. It's Template::Toolkit based but offers a model for building more integrated portal-like environments. I've been using it a bit but not really enough yet to say too much about it. One thing I like is that it has a built-in persistence/security model, SPOPS. This allows you to build portal objects with different access permissions for different groups/users. I'd like to hear other monks' impressions of OpenInteract if there are any out there using it.	[reply]
Re^2: Pondering Portals by perrin (Chancellor) on Dec 24, 2004 at 16:37 UTC
OpenInteract is a really impressive system, which takes on a lot of the anooying problems that other systems ignore: distributing your code as a an easy-to-install package, loading the SQL automatically, etc. It's worth checking out, especially with the new OpenInteract2 now available. Have a look at the YAPC presentation on the OpenInteract site for a good iintro.	[reply]
Re: Pondering Portals by borisz (Canon) on Dec 24, 2004 at 10:40 UTC
Take a look at pagekit.org. It is mature, very fast and works excelent with your existing database. Converting code from TT or H:T is very easy too. Boris	[reply]
Re: Pondering Portals by snacktime (Sexton) on Dec 25, 2004 at 06:55 UTC
Mason and the Template Toolkit offer very similar features and performance, and would be my first two choices. I personally use Template Toolkit a lot. With Template Toolkit you can keep perl code completely out of your template pages and put it all in your handler. I don't think you can do that as easy with Mason. Also take a look at memcached for caching queries on database sites, it's amazing.	[reply]
Re: Pondering Portals by SolidState (Scribe) on Dec 26, 2004 at 12:29 UTC
Slash. It should answer all of your needs, at least with regards to being scalable for heavily-hit sites (duh ;-)). Personally I've worked with HTML::Template and loved it - very easy, very maintainable (seperation of HTML from Perl code), but I can't say anything about how well it scales for sites that are heavily hit.	[reply]
Re: Pondering Portals by steves (Curate) on Jan 18, 2006 at 15:22 UTC
A year after this thread, I'm wondering where people stand on use of these bigger templating frameworks/portals. I want to pick up what I started with OpenInteract but there seems to be almost no activity there. I'm wondering if maybe just using Template Toolkit directly or switching to something like EmbPerl would be just as good. I also looked at Slash. I like the maturity and widespread use of it but it seems more oriented towards a discussion/news type of interface. What I'd ideally like is something that offers templating, the ability to make use of our existing Perl packages in dynamic pages without a ton of effort, and an inheritence type of model that allows all pages to share common characteristics in one place. Ideally I'd also have some sort of authentication/access settings to control access (e.g., have admin-type pages only privileged users can access). Content would be primarily presentation of data, mostly oriented around a set of jobs we run within an existing framework. Data would come from both databases and other sources (logs, files, etc.). We'd also want to hang documentation there, including automated POD extractions of packages we use and build. Any recent thoughts?	[reply]


Perl Monk, Perl Meditation
	PerlMonks