Slashdot Mirror

Have you been living under a rock for the last ten years? Of course web programming in PHP is easier than CGI! Just about anything is easier than CGI, not matter what language the CGI script is programmed in. If you want a similar (but more powerful) PHP-like environment for Perl, I highly recommend HTML::Mason. Two other interesting mod_perl environments are AxKit (centred around XML and XSLT) and Catalyst (a tight MVC framework). But they both are rougher to develop on, requiring restarts of Apache to load new code. At least Catalyst provides its own mini server for testing/development purposes.

Here here! My variation of the "LAMP" acronym is Linux, Apache, Mason, PostgreSQL. Working pretty damn well for me. I've been looking at AxKit on and off for a while, but who wants to use "LAAP"? :P

I'm actually developing new sites with AxKit.

This is not to say that patents aren't evil, but the best MS can do is to patent dying concepts, we have little to fear.

But, well, BTW, did I RTFPatent? Of course not! :-)

I hope they implement ASAP.

But there is another challenge, and that's the posts people write. Anybody care about their code? For example, quoting, to do it properly, one should write: <blockquote><p>blah, blah</p></blockquote>. That's an awful lot of typing.

A page is not going to validate unless the posts are correct.

The way I have planned to do this on one of my sites, is to make sure that every time somebody clicks "Preview" or "Submit", the post is handled to Tidy for sanity checks and conversion. By using preview, you can correct you're code, but you can never submit something that isn't well-formed.

I'm using Perl too, not Slashcode, but AxKit. Nevertheless, a good Perl implementation of Tidy is still lacking. There is a HTML::Tidy project page on Sourceforge, but it hasn't really gotten off the ground.

Does anybody else want to work on this, or do you have other ideas for cleaning up posts?

If you're doing your RSS smart, and generate static pages to be server while checking and sending proper conditional headers, then it really doesn't require that many resources.

The MVC model simply won't work under mod_perl

Hmmm, you must be smoking something good. Whilst there are some things you can't do under mod_perl (realtime perhaps), MVC is not one of them. In fact, you have an enourmous amount of choice when it comes to mod_perl and MVC - mason, Apache::Template, PageKit, AxKit and so on. There are many other tools to help you with MVC, or you can roll your own if you've sufficient hubris to think that none of the existing stuff does its job.

Please try to research your rants a little better.

-Dom

With mod_perl, XML::LibXML, XML::LibXSLT, I EASILY get 100/per second. and my code is shitty.

Amen. All of my XML processing code for the last year has been written using the above-mentioned tools, and it's been fast enough that I haven't needed to spend time performance tuning.

See the apache axkit project for more info.

Not to mention AxKit in those lists of templating systems?

You got some gremlins in your URL.

AxPoint

While I'm here:
Sample output
Source File

You got some gremlins in your URL.

AxPoint

While I'm here:
Sample output
Source File

You got some gremlins in your URL.

AxPoint

While I'm here:
Sample output
Source File

Use AxKit! You're selling yourself short if you start to develop a site without it. It's just the ideal way to get the whole separation of content and presentation thing that XML is supposed to be all about. It makes it dirt easy to store your content in XML, use XSLT for transformations and XSP for dynamic back-end processing. Check it out!

Also read this

simon

check it out. http://axkit.org/

"Apache AxKit is an XML Application Server for Apache. It provides on-the-fly conversion from XML to any format, such as HTML, WAP or text using either W3C standard techniques, or flexible custom code. AxKit also uses a built-in Perl interpreter to provide some amazingly powerful techniques for XML transformation."

picture coccoon for perl. using perl for xsp pages and doing pipline transformations on xml. great stuff.

Maybe a friendly group of Perl/XML gods will read the book and produce a framework/toolkit that the rest of us mere mortals can use.

That happened years ago: the Apache XML project's AxKit.

I recently decided to go with RNG for my schemas after reading up on W3C XML Schema (WXS) and Relax NG (RNG) . RNG is just so much easier to read and understand. The real clincher for me was the inability in WXS 1.0 to describe non-deterministic structures. I mean, give me a break. I can't allow people to put the elements in a different order? That's just lame.

What's more there's a fantastic tool dtdinst that converts DTDs into Relax NG. There's also tools to convert back and forth between WXS and RNG. So if I ever need to provide someone with a WXS schema I can just run it off automatically.

Now I'm working on a system using AxKit to parse out the RNG schema, generate HTML forms for completion, roundtrip the data back to the server, assemble an instance document using DOM and display it using XSLT and CSS. But that's another story. People who don't "get" XML should really check out AxKit.

simon

I'm afraid you don't know what you're talking about. SpamAssassin 2.50 uses *exactly* the same tokenising techniques as Graham's filters (in fact some more advanced ones too) as well as SpamAssassin's original set of heuristics. These are combined together to get an overall better picture of the email. See my presentation on this topic that I gave at the recent spam conference.

You might want to consider Apache's AxKit. While parts of AxKit are written in Perl to make it faster for us to write, the key parts that do the heavy lifting are written in C for performance reasons. Some fortune 500 companies are already running their site on it, and we get an awful lot of people coming to us from Cocoon for performance reasons.

It's a full apache project (under the XML umbrella), just like Cocoon is, and incorporates the same technologies (XSLT and XSP), but a lot of people skip over it because it's not Java. Maybe now is time to re-evaluate that decision.

Having looked at several CMS for a website I am going to relaunch, I needed an approach that was most general and would allow me to choose how I could store the content and separate the design. OK, the difference to the projects mentioned here is that I don't need a large system to manage things like user comments or other methods of dynamically adding pages. Currently I think I will go with AxKit, which is not really a CMS, but basically an on-the-fly caching XSLT processor. For me this provides the most flexible solution. I have designed an XML format to store my content files, and can then use either an XSL stylesheet to produce HTML or WML or whatever needed, or write an XPathScript style sheet allowing me to process the XML data while additionally using perl code to add dynamic features. The nice thing is that with AxKit you can use HTTP GET parameters to allow different style sheets (plain, xhtml, print, ...), pick a style sheet depending on browser type (lynx, netscape4, mozilla...), etc. And for a website offering mostly static content that needs to be organized in a proper way, I think separating content from layout using XML seems like a good idea. What I like to is that it's easily possible to include multiple language versions of your page in your XML data files and transform to HTML based on, say, a ?lang attribute. Plus, you could even store the XML content tree in CVS...

For websites that are just trying to be in control of their mostly static content, AxKit surely helps (provided you have access to the server box as you need to install the apache module...). Storing pure content as XML and then providing different stylesheets for layout seems a proper way to go for me.

Of course, this is not to say I don't like the LJ or E2 engines, butjust depending on what you need for your website, XML might be helpful, and AxKit might be the way to implement it.

Show me use cases, styles, patterns and examples of developing web applications with AxKit. Same about Redland, which suffers from the lack of documentation.

This book just repeats about XML what was already said in other books.

Java, along with J2EE, JSPs, and taglibs FORCE you to follow good practice and design. Its a lot harder to 'kludge' something up without still following design and OOP (granted, its still possible). Another thing I LOVE telling C++/Perl/ASP people is taglibs. No other language has anything similar. An HTML monkey, that has NO coding experience, can modify JSP's that utilize taglibs. It just produces XML that HTML monkeys view as just more HTML tags.

I think you should go to AxKit.org then and tell them they have nothing similiar :-) . It's a direct (I think) port of Cocoon from Java into Perl.

If you are looking for a complete interface to Perl/XML/XSLT then you should look into AxKit.

AxKit is a complete dynamic pipeline managment system for mod_perl.

I would agree with a number of the comments here concerning the use of XML as a data storage format. We use a relational database to store our information, output it as XML and format it with XSLT all using the AxKit pipeline. This allows us to output the information in any way that we see fit.

Please do consider AxKit, another official xml.apache.org project. It's the mod_perl/C equivalent to Cocoon. It's known to compile fine on Solaris and OSX, and because all of the transformation (XSLT) happens in C (using libxml/libxslt from the Gnome project) it's fast too.

Having said that, always consider what your programmer's skills are. If they're happy using Java they may not be too thrilled by a Perl or Python based framework. And sometimes hardware is cheaper than pissing off your developers ;-)

I think you need to look at AxKit instead!

AxKit.org

It's like cocoon but written in mod_perl (using Apache) and is much easier to get along with if you're not familiar with Java.

-Dom

But, FYI, Perl has a coupla thousand killer apps, most of which are available on CPAN.

Industry Standards include:

• CGI
• LWP
• DBI
• AxKit
• mod_perl
• and, of course, slash

The Beatles never flamed the Stones. The Stones never dissed the Beatles. And at no time did either party rip on Bob Dylan or badmouth Marvin Gaye. Language designers should celebrate their brethren. Particularly when the similarities so overwhelmingly outnumber the differences.

Perl is worse than Python because people wanted it worse. Larry Wall, 14 Oct 1998

Frankly, I'd rather not try to compete with Perl in the areas where Perl is best -- it's a battle that's impossible to win, and I don't think it is a good idea to strive for the number of obscure options and shortcuts that Perl has acquired through the years. Guido van Rossum, 7 Jul 1992

When I originally designed Perl 5's OO, I thought about a lot of this stuff, and chose the explicit object model of Python as being the least confusing. So far I haven't seen a good reason to change my mind on that. Larry Wall, 27 Feb 1997 on perl5-porters

If Perl weren't around, I'd probably be using Python right now. Tom Christiansen in comp.lang.perl, 2 Jun 1995

Python is an excellent language for learning object orientation. (It also happens to be my favorite OO scripting language.) Sriram Srinivasan, Advanced Perl Programming

XML is a rotten format for programming languages. Anyone who's worked with XSLT knows what I mean. XSLT (related to XSL) is, essentially, a programming language that converts XML documents into other XML documents and XSLT itself is (drum roll please) an XML document. Why? 'Cause XML documents are sooooo late 90's

XSLT is a great boon to Web developers and designers because it gives you a layer between what designers can touch and what developers can touch that acts as a sort of neutral zone. It also allows you to port your site between content management systems with fairly little pain.

For info on where this goes in the real world, check out XSP from Cocoon. This is a Java-based system, but there are XSP-based equivalents for other languages, namely Perl's AxKit.

Both of these technologies are Apache-specific, and in their early stages. I think for AxKit, the database interaction is the weakest link, but there's enough good mod_perl/DBI code out there that I don't see that as a big deal.

The first, and simplest, is mod_xslt. This is a very simple module that uses Sablotron for XSLT processing. How it works is by first breaking down the request at the file extension, so if you request foo.html it breaks it down into "foo" and "html". Then it looks for "foo.xml" in the same directory. It reads foo.xml for the doctype (basically looking for the name of the top level element). Say the top level element is <article>, then it goes and processes foo.xml with the stylesheet article_html.xsl. Notice that you can have different extensions actually requesting the same file processed in different ways.

That however is limiting, and doesn't scale too well (both in terms of site development and performance).

Your other option is AxKit. This is an Apache module that is built using mod_perl to make it easier to build, and provide a built in perl interpreter for scripting (AxKit is more than just a simple transformation module, its a full app server framework based around XML). AxKit provides more than just XSLT, it does XSP (eXtensible Server Pages, a technology in co-development with the Cocoon project), and some Perl based templating languages such as XPathScript and Template Toolkit. It supports some aggressive caching, which makes it run at about 60-80% of a raw Apache installation, and it supports automatic GZipping of output (for capable browsers).

There's also Cocoon, but you asked about Apache modules, which cocoon really isn't (unless you count connecting to a servlet engine with mod_jserv as an apache module).

yep, it's called AxKit.

I have tried Cocoon, but AxKit was much easier for me to set up. It requires mod_perl and Sablotron.