[Gllug] re: OSS CMSs

Fri Apr 29 09:59:55 UTC 2005

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.

> > Template provided awesome HTML templating capabilites
> 
> I guess most Java-types would use XSLT to transform data (in the form of
> XML) into XHTML. That's not writing it in Java, of course, it's writing
> it in the downright odd language that is XSLT. Java is pretty lacking
> when it comes to text manipulation (the addition of regex support to the
> core libraries in the 1.4 series helped here, but it's still hardly
> something Java can be called good at). An advantage of using XSLT is
> that it's pretty hard to produce XML output that isn't well-formed :)

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. 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. 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 can't imagine executing an XSLT transform is going to be as fast as
> Template either, somehow :)

I did some benchmarks of XSLT transformers, and the standard one bundled with
most apps (Xalan) 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. 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 :-)

> > and of course little things like DBI / DBD-PG
> 
> JDBC, which has drivers available for pretty much every database I know
> of, and there's SQL-J IIRC, which is a preparsed compile-time database
> library thing. JDBC's PreparedStatements are just the ticket for taking
> untrusted input and inserting it into an SQL query (compared to just
> concatenating a string together, which so many webapps seem to do,
> leaving their databases open to SQL injection attacks). No doubt DBI has
> something equivalent.

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

> > Log::Log4perl
> 
> AFAIK, a perl implementation of log4j so the operation of the two should
> be virtually identical

Yep, they're both very good.

> > Digest::SHA1
> 
> javax.crypto.* IIRC

Yep. Just make sure you grab the bouncy castle crypto providers to get
a full suite of crypto algorithms.

> > 'enterprise' java, no thanks - I'd still be working on it a year after
> > I'd started & it would be a pale immitation of what I knocked up in 
> > Perl ;-P
> 
> Can't say I'm all that keen on a lot of the enterprise stuff, especially
> the EJB-type bits. Seems a lot of work for a one-man project :) I guess
> it might pay off if you have a few hundred developers all working on one
> project, but when you hit that kind of scale, I guess the management
> difficulties are more trouble than the technical ones.

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.

Dan.

[1] I say portable, but in reality Perl runs on far more platforms than
    Java ever has. And OS portability is not an issue if you are aware
    of modules like File::Spec.
[2] Well, if you're crafty you can use ANT for 99% of work, and then have
    a custom task call out to launch WSAD & do the EJB generation behind
    the scenes, but that's just sick :-)
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20050429/09ae1896/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug