iw_include benefits?

Besides the obvious that when a page is generated with an iw_include that resulting page will not have to hit the server again because it now contains the include statically, what are the benefits of using an iw_include vs an old server side include?

Wouldn't it be a disadvantage since if you make a change to that include all the pages will have to be regenerated?

Thanks,
Nico

Find more posts tagged with

Comments

Adam Stoller

As with many things that are optional - there are costs to be weighed.

On the one hand, yes - if you change a file that is iw_include'd, you need to regenerate all the pages wherein that file was used.

On the other hand, if you hard-coded the same thing into multiple presentation templates, and then wanted to change it in all of them, you would have to modify all those templates and *then* regenerate all the pages.

If you went the route of using a SSI - then you're paying a cost on the server for processing that include file. On a individual page-by-page basis, the cost is probably pretty miniscule. But if you consider all the various pages that all your various web-customers could be looking at in any given point in time, it could add up to a noticable load on your server, which can translate into less-than-desireable performance to your end users ... and in some cases may cause you to loose some of those end-users (or so I've heard).

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

It can be a serious disadvantage. HTTP servers are optimized for serving files and cache includes and even entire dynamic pages. The overhead of a dynamic include is miniscule.

On one project an agency delivered iw_include had been used for the footer on every page, which had a copyright date in it. When the next year rolled around and it came time to change the date, there were thousands of pages to change. The Workflow system doesn't exactly like that situation, especially when those files are already involved in workflows or other changes are being made to them. Compare that to changing one include file.

Plus, static HTML is a thing of the past. If you are writing pages with .html extensions, consider changing it to ASP, CFM, etc. Again, the processing overhead is minimal, but if you do eventually decide that a page needs some dynamic content, you wouldn't have to change all of the links to that page just because you changed the extension.

I would *NEVER* use iw_include.

MattP

Nico-
I just finished a project with using IW_INCLUDE s and the site absolutely flies! Yes, there is the slight disadvantage to regenerating all the files after updating, but for me, it is worth it. It is easy to "select all files" and regenerate. As well, I was given some perl code that will check for updated files and regenerate if necessary. As discussed above, yes there are pros and cons that you will need to consider for your specific project.

Good luck
Matt

Matthew Petitjean
BOC Group
Murray Hill, NJ 07974 USA

laj1

"If you are writing pages with .html extensions, consider changing it to ASP, CFM, etc. Again, the processing overhead is minimal, but if you do eventually decide that a page needs some dynamic content, you wouldn't have to change all of the links to that page just because you changed the extension."

On second reading, I understand that what you're advocating is using an extension other than .html, one that correspondes to a popular dynamic page generation tool like ASP (.asp) or Cold Fusion (.cfm) and then configuring your web server to know to server those extensions as static HTML docs.

But I have to wonder, whether this is worth the minimal hassle of performing a global search and replace to correct links, if and when you chose to go ASP/CF/JSP/SSI.

Now then, just to be perfectly clear, there is more than minimal overhead in running the dynamic systames like ASP or Cold Fusion.

Len.

Len Jaffe
My Heart Is A Flower

nico

Thanks to all of you for your great input.

Nico