[Gllug] re: OSS CMSs

Tue May 3 14:35:31 UTC 2005

On Fri, Apr 29, 2005 at 10:59:55AM +0100, Daniel P. Berrange wrote:
> On Fri, Apr 29, 2005 at 01:27:35AM +0100, Russell Howe wrote:
> > > To name but  a few, Mail::Box provided for loading of arbitrary mail
> > > box formats and MIME message decoding,
> > 
> > Like JavaMail then :) There's a JavaMail plugin to handle maildir
> > access on sourceforge which seems to work well.
> 
> If you can get good plugins for mbox, maildir, & all common UNIX mail 
> box formats, then it looks like it'd be reasonable.

If nothing else, it can do IMAP, although that then means you have to
authenticate against the IMAP server.

> I've had the misfortune to spend 3 years working in Java using a framework
> of XML & XSLT for presentation and have come to the conclusion that while
> it is applicable in situations where you want to provide well defined output
> for interoperability with other systems, for general web page templating it
> is just a disaster.

I'm not sure if what I'm doing classes as templating or not... it takes
something like this:

<cv>
	<name>Foo</name>
	<d-o-b>28th January 1861</d-o-b>
	<qualifications>
		<qualification>blah</qualification>
	</qualifications>
	<!-- etc -->
</cv>

and processes it into a JSP document (the downright odd term used to
describe JSP's XML representation).

> Sadly there is no widely used equiv of Template-Toolkit
> in Java, and its much the worse for it. One touted advantage of XSLT is that
> web designers can quickly take your XML, change the XSLT to generate new HTML
> output, but in reality that just doesnt work.

XSLT? Quickly change? heh.

> I can count the number of web
> designers who are comfortable with using XSLT & XML for templating on one
> hand. And besides, these days, web designers are much much more in tune with
> awesome capabilities of CSS, so changing the raw HTML is very much less
> relevant than it was 5 years ago.

I still use CSS for the visual layout, but wanted to store textual data
in XML and have it presented via the web. XML seemed pretty suited to
this (the other alternatives I could see were to store it in some other
structured text format, or in a database). The XSLT to JSP step lets me
use JSP custom tags to do fancy stuff at run time, but make the XSLT
transformation happen just once, when the source XML changes. The JSP
then gets compiled and should be as fast as any other page on the site.

One example is I have a <link> tag, used like so in the XML source:

<link name="google">This is a link to Google</link>

When translated to JSP, this produces something like:

<links:link name="google">This is a link to Google</link>

and when executed, the link tag from the links tag library goes and does
a database lookup to supply the URL linked to by the text 'google'.
Pretty heavy on the database, you might think. My view is that the
box running MS SQL Server is way overspecced and needs to earn its keep
:) The site's low volume though, so it probably wouldn't matter from a
performance point of view if for every page request the server went and
retrieved each character of the result via a SOAP call to an entity EJB
which used bean managed persistence to retrieve data by emulating a
VT320 and pulling stuff out of an old serial console-based system :)

> I did some benchmarks of XSLT transformers, and the standard one bundled with
> most apps (Xalan)

And now bundled with the JRE itself, since v1.4

> is 5x slower than the fastest (JD.XSLT). Even the XSLTC
> which compiles XSLT files into Java code for supposed speed, is 1/2 the speed
> of JD.XSLT. But every java solution I've looked at pales in comparison to
> transformers written in C.

I hear the libxml folks are rather proud of their performance.

> So if you were to go down an XSLT route, you'd want
> to let the transform be done in Apache with mod_xslt or some such. But is it
> really worth the hassle, when you can do the same thing in Perl with
> Template :-)

I avoided that particular bit of hassle by ensuring that the transform
wasn't per-request, but per-edit of source :)

> Although they offer same basic capabilities JDBC is a PITA compared to
> DBI mostly thanks to Java's strong typing model. 

Yeah. Still looking for a nice way to pull data out of a database and do
updates without too much hassle. JDO looks like it's what I should be
using, but I keep avoiding it for some reason.

> In the experiance I've had with it, EJB seems to basically be a very good
> way to get vendor lock-in in an otherwise 'portable'[1] language. To wit, if you
> want to run you app in WebSphere, then you have to use IBM's EJB compiler
> which basically means you then have no choice[2] but to use WSAD (IBMs crack
> laden version of Eclipse) as your development platform.

Orion (www.orionserver.com - free as in beer for devlopment, £££ for
anything else and not open, and no, nothing to do with me) should at
least in theory allow you to bundle everything up yourself and have it
work, but last time I tried to write something EJBish all I got was a
weird stack trace :)

I eventually managed to write a message-driven bean. Can't remember what
it did though. It was to do with the JMS<-->syslog bridge I was writing.
JMS looks quite neat, although I'm not aware of a standalone 'JMS
server' application, there must be one around.

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe at siksai.co.uk | when you can be the spanner in the works?
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug