Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Announcements Software Apache

Mod Layout 3.0 Escapes Beta 24

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Mod Layout 3.0 Escapes Beta More

Mod Layout 3.0 Escapes Beta

Comments Filter:

  • Re:Why not use a preprocessor? (Score:1)

    by Anonymous Coward
    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.

  • Wrong Approach (Score:1)

    by Anonymous Coward
    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 [mozilla.org], Internet Explorer has MSXML, and Galeon uses Daniel Veillard's excellent libxslt [xmlsoft.org] 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 [onlamp.com] method of dynamic web service; it actually pins people down to a specific server capability that is rare, immature, and ultimately useless.
  • 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 <body> and </body>.

    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
  • This is true. It would help those with not a large amount of ram. But seeing as you can pick up 256megs of good quality ram for ~35 bucks a pop, I'm not too worried :^)
    -Moose
  • ya got me there :)
  • 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,
  • 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

  • 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
  • Is it just me, or was this item originally posted to the frontpage, as well as the Apache section?
    signature smigmature

  • Re:Interesting (Score:3)

    by gengee ( 124713 ) <gengis@hawaii.rr.com> on Sunday July 22, 2001 @08:12PM (#68455)
    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

  • Re:Why I don't use apps like these (Score:4)

    by gengee ( 124713 ) <gengis@hawaii.rr.com> on Sunday July 22, 2001 @08:17PM (#68456)
    I was thinking the same thing, 'till I followed a link to the documentation [tangent.org]. It has quite a bit more info about the project.
    signature smigmature
  • 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?

    Although many (such as myself) have built "block" and page caching components utilizing the simple "http GET, save to cache file, index in global hash table" or similar techniques, having this in an apache_mod has two benefits:
    1) It's compiled, so it will run faster than your scripts.
    2) It's implemented BEFORE it hits your dynamic engine so it lessons the load to mod_perl|php|cf etc.

  • Why not use a preprocessor? (Score:3)

    by Erasmus Darwin ( 183180 ) on Sunday July 22, 2001 @08:15PM (#68458)
    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) [tuwien.ac.at]. 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.

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

  • Ok... but... (Score:3)

    by kstumpf ( 218897 ) on Sunday July 22, 2001 @08:54PM (#68460)
    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?

  • Not to say that mod_perl is bad or anything, but it DOES add a few more megs of memory to each forked apache process. Coding a module in C doesn't do this.
  • Dude, you're so right! I'm still confused about how this became slashdot-caliber (don't laugh) news when there are thousands and thousands of other OSS projects that are even more active than this one that go unsung. There are even lots of other portal-related apps like SIPS or PHP-Nuke or PHP-j00k that are being hacked and whacked day in and day out, with very little media recognition.

    Maybe /. can have a special Announce-back blurb once every week or so, mentioning some nifty program releases or updates. Or, just have a freshmeat slashbox or whatever. Or, just don't care like I do.
  • (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

  • 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

  • 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?

  • isn't this nothing that can't be done with the skills learned in that "Learn Perl in 24 hours" book?

    Actually, this is an immensely useful tool in a couple of circumstances (especially involving static pages). Consider any of these cases:

    • You run a "host your own web site for free" system like GeoCities and you want to stick your JavaScript ads on the top of each page. This is far more elegant than running a cron job to hack every user's page each night.
    • You maintain some sort of reference system that accepts html files from a third party, html files that are automatically generated by some other system, or html files that are maintained by a different person than the rest of the web pages. This module makes it extremely easy to add a "contents/up/back/about/..." header or footer to every page, and not have to worry about changing the header on a couple hundred documents when you want to change it (e.g. change "up" into an up arrow icon).
    • You use some perl cgi's here and there, and you don't want to make them even less maintainable than they already are.
    This module will work wonders for site maintainability. I know that the webmaster where I work is going to be implementing it next week for parts of our intranet.

    -all dead homiez

Slashdot Top Deals

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Close