forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Forrest: dynamic or static?
Date Mon, 22 Sep 2003 12:21:12 GMT
Jeff Turner dijo:
> On Mon, Sep 22, 2003 at 12:25:49PM +0200, Juan Jose Pablos wrote:
>> Jeff Turner wrote:
>> >Then we have:
>> >
>> > - The addition of XSP.  Lots of uses with dynamic Forrest, none
>> (that I know of) for a statically rendered site.
>> I gave you an example of XSP use for static rendered site.
> You said you wanted to use it for retrieving data out of a database.
> What kind of data?  What percentage of Forrest users do you think share
> this use-case?
>> Plus this was requested by users!
> About 4 users in total (including yourself).  I'm sure they all have
> legitimate reasons for wanting XSP capabilities, but I don't think the
> vast majority of Forrest users share this need.  Call a vote if you
> think otherwise.

I dont like the idea of XSP into a Forrest as a documentation tool, but
can you draft an example where we need to use XSP in order to write the

>> > - Lucene integration.  As it exists in CVS, it screws up statically
>> >   rendered sites, so is disabled.

I think it would be disabled by default as the google feature currently
is. Let the user decide to use one of them, or none. The idea of both
sounds weird, Then we can join them in just one property. Is this correct?

I am in favor including Lucene. I think any documentation project must
have a searching tool. For online sites we have "google search", for
Intranets Lucene is a good candidate to do the job. Can someone point to
another solution in this area? (Not ironic, is really a question). I saw
the idea of htDig, but I dont see this a good idea at all.

>> >Being a Cocoon distribution, there is a huge amount of stuff that
>> Forrest *could* include.  I think we need to draw a line, define what
>> Forrest actually is, and stick to that.

I dont see it totally black or white. We must concentrate in what is good
for writing documentation. That is the goal of Forrest at all. Of course
we can find a case for every cocoon stuff that can be related to writing
docs (even remotely). But this is not the point.

>> >The line I propose is that Forrest should be regarded as an offline
>> site generation tool that happens to have an online mode for rapid
>> page development.  There should be no features _unusable_ from a
>> static site.

Yep. This is part of the overall idea:

>> >For especially useful features, like searching, we can bend the rule
>> and have online/offline equivalents (lucene and google).


> The ability to run a Forrest site dynamically during development is a
> huge advantage.  Nobody is suggesting getting rid of it.  I'm suggesting
> that as a rule, we do not include features that 1) *only* work online,
> 2) are used by only a few users.


Best Regards,

Antonio Gallardo

View raw message