Bill Moseley wrote:

At 10:44 AM 01/28/02 +0800, Stas Bekman wrote:

Of course, silly me :)

But that's easy. We just prepare a special template during the rendering, which will be an html with everything inside + a placeholder for search results. Piece of cake. Right? We should need only one static page for this as all the hits will have their links from /.


That's fine. If DocSet can build me a page with just a [% content %] section where you want the results, that will be easy. My existing template is designed to use with WRAPPER, so that will make things simple.


Yes, simply add an html page ala src/404.html and add it to src/config.cfg into the hidden section ala 404.html. Call it searchresults.html?

See cvs, I've just added this page.


We could always hard code the layout for the search script.  Would be a
little faster than loading TT for each search.  But it would be nice to use
the script.


Yes, I think you don't need TT here at all. A simple s/// will be faster. So we better use a different placeholder than [% results %]

e.g. [RESULTS]


So with docset, if I modify one page and run /bin/build, it knows to only
build that one page.  But what if a change in a page modifies how the
sidebar menu will look will DocSet go and re-build everything?


The logic is more complex than that.

If you change a page, config file or any of the files that are copied as is, the docset this changed object resides in gets rebuilt. And of course all the parent level docsets are rebuilt as well.

It tries to do the right thing doing the minimal work.

If you change any of the templates, you should rebuild the whole thing with -f (force). Since templates don't change a lot, we don't want to involve extra logic in source modification alg.


Maybe when you can't sleep some night think about separating DocSet from
the HTML generation. It might be nice. DocSet -> ttree -> html output.
DocSet might write a tt config file, or provide a plugin to read the cache.
You might end up with a more powerful solution where DocSet, CGI, and
mod_perl could be used together in a site.


Nope, not DocSet. That's how Andy's TT docs get built - in two passes. I don't like this approach because his templates look like hell (the first pass need to generate templates for the second pass) and if you look at the pods, they have loads of TT markup in there.

DocSet builds everything in one pass, but in two phases - first scan everything and cache the wanted bits then render it all. No circus acrobatics required.

DocSet should also be able to
read a config.  For example, if you wanted "Search" to be a menu item, but
Search is not part of "src" then it might be nice to have a way to tell
DocSet to include that.


You can do this already, look at the src/config.cfg file. and search for [EMAIL PROTECTED], now do the same for search.

Didn't I tell that DocSet is a dream app for the docs repository manager? It does all you ever possibly want to do :) :) :)


so you say that it didn't copy the dot files from the search directory, right?


Right. But odd. I did a cvs update and bin/build and now the .htaccess you added was copied.


May be you've forgotten to save the config file? I've got it working the moment I've added it. Or there is a bug.


Also:

.../dst_html/.htaccess: Redirect to non-URL


what do you mean? This entry is wrong?

RedirectPermanent /guide/ /docs/1.0/guide/

How do I fix it? Just "Redirect"?


BTW, update your cvs, I've added an .htaccess file at the root dir already.


I thought I just updated a few hours ago. ... Oh, now there's the update.


:)


<!-- SwishCommand index -->
    [% content %]
<!-- SwishCommand noindex -->

I'll commit it immediately.


Yep, that's it.


committed, see if something is missing. like an earlier 'noindex' tag.

Add libxml2 to swish-e was a very nice thing.  The old
html and xml parsers in swish really sucked.

But then I get "bug" reports where javascript was being indexed:

<script>
<!-- hide from old clients
 some javascript here
// end of hide -->
</script>

The old swish HTML parser would ignore the java script inside the
"comment", but libxml2 (correctly) seems that as CDATA and it was indexed.
Libxml2 makes it easy to add


  IgnoreTags script style

And fixed.

One more bug to fix before I sign off.


cool!


Let me know when you can generate a template for the search script to use.

it's done.

--


_____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to