in reply to Re: Re: Re: Script generated site index db
in thread Script generated site index db

This is still very much a half-solution for sites that incorporate dynamic content or server-side includes. For sites such as these, for which I first looked into this issue, a local-based HTTP indexing engine is an absolute must - It should also be noted that indexing can be scheduled for low-utilisation times and the impact on the server is minimal.

The other advantage which this approach offers is the ability to incorporate web site maintenance such as broken link checking and content-auditing into the same process.

 

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'

  • Comment on Re: Re: Re: Re: Script generated site index db

Replies are listed 'Best First'.
Re: (5): Script generated site index db
by shotgunefx (Parson) on Mar 19, 2002 at 09:59 UTC
    I totally agree that munging files is a less than ideal solution. Not an insult to S_Shrum but when I saw that he was working with flat files and planning on searching flat files I geared the answer towards the question.

    When possible, I think that indexing is best part of the publishing process. If you're working with the data files that generate a site, you're in a much better position to know what data is relevant and in what context.

    Most of our clients have their data piped through us at one stage or another and it makes it much easier. For instance, if you have a global footer on every page that contains a keyword, you probably don't want to return every page back in the results. To try and detect things like that looking from the outside would be pretty difficult.

    -Lee

    "To be civilized is to deny one's nature."
[reply]

In Section Seekers of Perl Wisdom