Slashdot Mirror
Mod Layout 3.0 Escapes Beta
Brian Aker (AKA Krow) sends word that the mod_layout Apache mod has arrived after a long beta period at version 3.0. From the project's page: "By allowing you to cache static components and build sites in pieces, it gives you the tools for creating large custom portal sites. If you are looking for more information you can look at its faq."
It works with anything. Perl, PHP, Java... the nice thing is that you don't have to edit all of your own content, and you can force headers and footers on users contents.
This very obviously is an extension of wrong-minded approach to managing content online. The future is in client-side transformations and page construction, lightening the load on servers (so anyone can run one) and making caching mechanisms more effective. XSLT is one method of doing this. Mozilla is working on TransforMiiX, Internet Explorer has MSXML, and Galeon uses Daniel Veillard's excellent libxslt for transforming stuff on the client-side. Using the document() function lets any XSLT stylesheet basically get parts of the complete page from all over the web and compile them into one document on the client side. Doing this work on the server side not only doesn't improve the oh-so-basic LAMP method of dynamic web service; it actually pins people down to a specific server capability that is rare, immature, and ultimately useless.
Consider a situation where people are using WYSIWYG editors. Maybe they are all using the same editors -- but probably not. Some are probably even using Word. And even if you standardize on an editor, my experience with the templates these editors provide is that they are less than robust. They also require training -- it's very easy for someone to create a page that seems to fit with the overall site look, but are actually static and won't update.
A preprocessor won't work, because then there's a whole complexity to updating the site -- they can't simply upload a page, because it will be in a raw form and the preprocessor has to be run. That sucks. All the programs just support FTP, everything else requires all sorts of training and the inevitable mistakes.
PHP sucks for this. Really. WYSIWYG don't let you create invalid HTML pages -- that means there will be a <head> and all that, and if people have to put the <? echo header(); ?> crap in their pages you are burdening them with a lot for little benefit.
So this leads you to mod_layout. I've implemented the same thing before in PHP, Perl, and Python -- which is only to say: it's really useful, I've really used this sort of thing and been happy with it, and I bet an Apache module will do it faster than the P* languages.
Pardon my inquiry, but isn't this nothing that can't be done with the skills learned in that "Learn Perl in 24 hours" book? Why reinvent the wheel if you don't have to?
-Moose
more large custom portal sites... "it gives you the tools for creating large custom portal sites."
I would take a chance and check it out. I like fact that they spend less time talking about mod_layout ...
and more time working on it.
They keep the brag ratio down, and the productivity ratio up. We need more people with attitudes like this, and less people like John Romero (maker of Dai*cough*tana).
========================
63,000 bugs in the code, 63,000 bugs,
ya get 1 whacked with a service pack,
--- Grow a pair, liberals... stop letting the Republicans bully you!
I'm a pro web developer, and my toolbox is constantly evolving. This app for Apache sounds really interesting, but why can't they SELL it a little. There's something like four sentences on the project page. And that's the only page. When I see something like that I go "Hmm, if they can't be bothered to describe what the app is and does beyond a blurb, then it can't be very good".
That's probably not at all correct, but I simply don't have the time to test every single thing that gets released, I need them to convince me that it is worth my time. Since I'm really rooting for the little guy, I think it is a shame that they can't go that extra mile.
Mod layout isnt designed to really work with frames since the author "doesnt like them"
:)
It allows you to add footers and headers to a page as well as text before and after a certain tag.
It doesnt matter if the content is produced by PHP, Jsp, Static whatever.. it will still work. IE: It goes after your PHP page, wonder how this works with output buffering tho.. hmmmn?
It ships with a BSD style license.
Meaning basically after all is said and done this can add in a couple of extra things so that you dont have to do so in your code.. In practice this might get a little messy without a well designed and managed project
You can also include Perl scripts for the header/footer. Possibly PHP / Java etc, but im not exactly sure how this works just yet.. Just playing with it
So basically if this fits within your development model or fills the niche it was designed to for you by all means use it. It is just designed to do one thing and do it very well. I think that I could find some uses for it in quite a few situations. Especially text before and after a tag
Jeremy
Is it just me, or was this item originally posted to the frontpage, as well as the Apache section?
signature smigmature
- James
Personally, I can think of two reasons for mod_layout, though neither one is especially compelling:
Overall, I personally don't like the Slashdot blurbs that link to a less-than-informative release message that was probably kicked out by a programmer who'd just spent the last N hours killing bugs and is in a hurry to get things up and available. I don't blame the programmer (who's doing a public service, usually for free), and I don't blame Slashdot (their role is mostly as an index rather than a direct content producer), but I still wish there was something a little more concrete, short of wading through the documentation of the actual module.
Recent reports show that in order to optimize revenue OSDN has decided to combine the popular sites Slashdot and Freshmeat to great the mega portal, slashmeat.
E-mail address is backwards.
Personally, I strip my Apache config down to the bare essential modules I need. This seems neat, but covers ground already tread upon long ago. Am I missing something?
I use mod_layout on my sites, and I love it. It fills a need I've been looking for for a while.
All of my sites are a combination of static and dynamic pages -- with the dynamic pages being generated by multiple sets of programs, and many of the static pages also generated programmatically.
Creating a site interface for something like that is a bear -- and changing it is worse. To install updated graphics or redo the look of the site, you had to patch multiple sets of programs, or hack the programs to read the header/footer and attach them on the fly (which meant hassles every time the program had to be updated instead...). The static pages: good luck.
And, of course, the designers who own the interface want it changed at 4PM on a Friday with four hours notice.
Now, it's two files, one for the header, one for the footer. It needs changing? change them and restart Apache. My maintenance headaches have been cut by a huge amount, and updates are now trivial, so we're more willing to fix things or improve stuff when we find better solutions. bEfore, it was a major hassle -- so it tended to wait, even fi we didn't like something.
And it basically just works. And the people who create content don't have to worry about the interface, the admins don't have to worry about re-skinning stuff when the templates change, and you don't have to worry about whether or not all of the changes have been made in all of the places at the right time. It all happens magically inside Apache.
Truly wonderful. If you're doing something straightforward and fairly simple, it's probably not a big deal (but even then, I think having the interface completely separate from the content is a really Good Thing, since it makes it impossible for one to screw up the other, or for an author to botch things...); build a complex system that involves multiple packages from multiple programming groups in multiple languages, and content from half a dozen groups and four different programs, and suddenly, this is a great thing to have...
I'm now starting to look at re-doing the corporate intranet using it, because of that separation between interface and content, and the hassles that happen when authors have to worry about interface issues, even with good tools and templates.
Mostly, though, it's simple -- and it just works. And it really cuts my maintenance hassle. How can this be bad?
Chuq Von Rospach, Internet Gnome = When his IQ reaches 50, he should sell