Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mod Layout 3.0 Escapes Beta

Posted by timothy on from the making-things-pretty dept.

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."

12 of 24 comments (clear)

  1. Re:Why not use a preprocessor? by Ian+Bicking · · Score: 2
    Looking at the docs, it can insert HTML not just at the top and bottom, but also before or after any tag. Particularly interesting tags are and .

    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.

  2. Why I don't use apps like these by 17028 · · Score: 2

    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.

    1. Re:Why I don't use apps like these by gengee · · Score: 4

      I was thinking the same thing, 'till I followed a link to the documentation. It has quite a bit more info about the project.
      signature smigmature

      --
      - James
  3. Re:Interesting by gengee · · Score: 2

    True, but no matter how much memory you have, it can -always- be used by something. Why waste it if you don't have to?
    signature smigmature

    --
    - James
  4. Removed from frontpage by gengee · · Score: 2

    Is it just me, or was this item originally posted to the frontpage, as well as the Apache section?
    signature smigmature

    --
    - James
  5. Re:Interesting by gengee · · Score: 3

    If you're running a website that get's 500,000 page-views per day, that's a lot of Perl processing just to put a header/footer on every page. Mod-layout provides caching, which I can imagine may take quite a bit of load off of a large website.
    signature smigmature

    --
    - James
  6. Why not use a preprocessor? by Erasmus+Darwin · · Score: 3
    From what little information there is, I don't see how this is significantly different from using a preprocessor to add static elements to your webpages. The one that I'm mildly familiar with is the Chakotay preprocessor (chpp). It seems preprocessing the pages would be more computationally efficient (do it once rather than every time you serve a page). (As a side note, does anyone have a favorite preprocessor? I never really got into chpp and don't know how it compares to some of the other ones out there.)

    Personally, I can think of two reasons for mod_layout, though neither one is especially compelling:

    • Completeness - There's no major "cost" to having mod_layout available. If someone doesn't use it, they don't incur any extra overhead. If they do use it, then it's solving a need.
    • CGI stuff - I'm not sure, but it appears that mod_layout might work on things other than straight .html files. Since those can't be preprocessed, mod_layout would be the way to go (unless you wanted to manually add the static elements to each CGI, which is feasible in some cases, but can sometimes be a pain in the ass).

    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.

    1. Re:Why not use a preprocessor? by einhverfr · · Score: 2
      (As a side note, does anyone have a favorite preprocessor?...)

      You are asking the /. community? Of course many will say PHP... That is what I use. While mod_layout looks interesting PHP does everything I want it to (I can store static pages as binary large objects (BLOBs) in MySQL and get a similar effect if I want to) and it is widely supported. Still looks interesting.

      Sig: Warning The following may be illegal under the DMCA (rot-13 decoder):
      ABCDEFGH I J KLM

      --

      LedgerSMB: Open source Accounting/ERP
  7. In other reports... by Foo1 · · Score: 2

    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.
  8. Ok... but... by kstumpf · · Score: 3
    What I'm trying to figure out is why I would run this module instead of just using mod_include for straight markup, or include() or virtual() in PHP docs. And in the latter case, you can use PHP cache and save some disk hits. This is what I've done for years... it works great and requires no httpd.conf modification.

    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?

  9. Re:Just what the world needs... by einhverfr · · Score: 2
    more large custom portal sites... "it gives you the tools for creating large custom portal sites."

    So? It makes perfect sense in many instances. A good example would be a company intranet-- imagine being able to offer a customizable page to your employees with the features that they need. Not that there aren't a plethora of portals on the internet but that is a separate matter.

    Sig: Warning The following may be illegal under the DMCA (rot-13 decoder):
    ABCDEFGH I J KLM

    --

    LedgerSMB: Open source Accounting/ERP
  10. why I use mod_layout by chuqui · · Score: 2

    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