moseley at hank
Jan 27, 2002, 3:00 PM
Post #13 of 20
(1043 views)
Permalink
|
At 01:08 PM 01/27/02 +0800, Stas Bekman wrote:
>> Do a normal indexed search for most, but offer an option to search for perl
>> code and then use fgrep.
>
>OK, so how hard would be to have a simple prototype to play with?
Which part?
Indexing the site with swish is easy and can be setup in a few minutes. I
just did it in my modperl-docs copy.
Once we have a script running we can worry about searching perl code.
fgrep might be a quick hack. I wouldn't worry about speed or machine load
at this time. For now, let's wait until we have a problem before we solve it.
The hard part, at least for me, is integrating with DocSet.
One problem, from what I can tell, will be that the template variables that
DocSet creates from parsing the source files are not available for CGI
scripts run outside of DocSet. So a CGI script will not be able to use the
same templates.
Also (minor point), with out looking too hard, I noticed that DocSet didn't
copy dot files (.htaccess .swishcgi.conf), and also didn't keep permissions
(so CGI scripts lost their execute bit). At least that's what it looked
like. Hum, I'm sure there's a way to do that, but out of time now.
Some minor details:
I assume spidering is the way to go (instead of scanning the "src" directory).
It makes most sense to index what people can actually get to by following
links.
Also, the templates should have processing directives for swish. This is
what I do:
...
<body>
<!-- SwishCommand noindex -->
...
<!-- SwishCommand index -->
[% content %]
<!-- SwishCommand noindex -->
...
Then swish is indexing the <head> section, and then only indexing content
(and not menu text and so on).
Stas, if you know how to deal with integrating a CGI into the templates
with DocSet, cool. But, I don't see how, unless DocSet is writing a file
that can be used by TT (PRE_PROCESS) to give the CGI script the same
template variables available when DocSet is running.
<just and idea>
One idea for the HTML output part of DocSet would be to write an
intermediate site ready for use with ttree. That might allow easier
integration with CGI scripts or just plain content that works outside of
DocSet, since not everything will be content. I think using ttree is
rather flexible.
In other words, let DocSet build it's data structures such as the overall
site menu (table of contents), with attached abstracts if needed, and write
that to a TT config file. Write the source docs out as if they were source
files for TT content -- or even as BLOCKs for use in other templates. Use
[% META %] tags at the top of each file to set UP, NEXT, PREV, breadcrumb,
and anything else that's page specific.
Then run ttree to generate the final site. The advantage is that the
DocSet site can be extended with source outside of the DocSet system. Not
to mention that things like CGI scripts can be processed with ttree, which
can PRE_PROCESS the config file created by DocSet so it can use the same
templates (and template variables) to format its output page the same way
DocSet pages would (i.e. with the same menu items). Also paths can be set
in the CGI script based on TT variables, instead of hard coded.
Or another idea: Don't you cache a lot of data? So maybe we just need a
plugin that reads that cache into template variables and use that with CGI
scripts outside of DocSet.
I like the first idea better, as it separates TT from DocSet. Plus it
allows a TT driven site to be enhanced by DocSet instead of trying to make
DocSet do everything.
</>
But, of course, you probably have already thought how to solve this.
--
Bill Moseley
mailto:moseley [at] hank
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe [at] perl
For additional commands, e-mail: docs-dev-help [at] perl
|
