Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Beatnik (493)

  (email not shown publicly)

A 29 year old belgian who likes Mountain Dew, Girl Scout Cookies, Tim Hortons French Vanilla Flavoured Cappucinno, Belgian beer, Belgian chocolate, Belgian women, Magners Cider, chocolate chipped cookies and Perl. Likes snowboarding, snorkling, sailing and silence. Bach can really cheer him up! He still misses his dog.

Project Daddy of Spine [], a mod_perl based CMS.

In his superhero time (8.30 AM to 5.30 PM), he works on world peace.

Journal of Beatnik (493)

Friday December 12, 2003
07:44 AM


[ #16306 ]
In my quest for writing a better CMS, I stumbled upon yet another list of known CMS'. Ofcourse, I started visiting pages, reading documentation and feature lists. Quite a few have features that stop me from experimenting with them.

Based on Java - Server side : Call me stupid but Java on serverside still gives me goose bumps. It's slow as hell, I've seen too many of them blow up and it requires extremly exotic system setups. Not really something I'd pick for a quick installation.

Based on Java - Client Side : Ofcourse it is nice to provide a tool for remote administration but to only allow access through a client side Java tool forces the user to comply with JVM requirements etc. Java explodes a lot.

Based on PHP : PHP, IMHO is nice for quick hacks but when I see it in a CMS, I always feel like the programmer expects the users to do their programming too. Too many PHP programmers want to force their users into using PHP. Yes, it is becoming a less exotic server feature. Yes, it can do quite nice things but at the point where you allow your users to execute code, it's getting too tricky for me. Any CMS where the user is expected to do some programming, is IMHO a wrong choice. You should give possibilities. Once a PHP project grows, it tends to become unmanageable. This link has appeared before but it summarizes quite nicely how I feel towards PHP.

Based on XML : We all know XML is just plain text. IMHO, it's OK to use in data transaction or in config files but to use it in CMS' to store everything is a bit too much. Parsing XML is quite slow and usually requires some extra module installation... and to what gain? Just a Buzzword thing, IMHO.

Exotic formats : A few CMS' include features to import and export using platform dependant formats (for instance Word). This, again, requires some extra dependencies on the server side; dependencies the server administrator might not want to resolve...

Steep learning curve : If I have to play around longer than X minutes before I see result, I drop it. It should be easy enough for quick results but advanced enough for complex setups.

Portability : ANY doesn't mean Any server that supports X . Any means ANY .

RDBMS : If it's a really simple system, going for a DB is overkill. It will cause unnecessary overhead, installation is far more complex.

Ofcourse, I'm quite guilty on a few of those counts. The most important thing to think about is ofcourse common sense. There is a lot of unnecessary stuff out there (mine included). Trying to keep it simple though flexible is my main goal... Oh yes, Documentation is also pretty important

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.