You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/09/20 15:44:14 UTC
Forrest: dynamic or static?
I see we now have i18n'ed menus, where the language is chosen based on
the locale of the requester.
This feature is useless if you're rendering a static site with the CLI.
The requester's locale will be that of the local machine.
Then we have:
- The addition of XSP. Lots of uses with dynamic Forrest, none (that I
know of) for a statically rendered site.
- Lucene integration. As it exists in CVS, it screws up statically
rendered sites, so is disabled.
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.
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.
For especially useful features, like searching, we can bend the rule and
have online/offline equivalents (lucene and google).
I can demonstrate why I take such a hardline stance with a small
benchmark:
jeff@expresso:~$ ab -n 50 -c 10 http://localhost:8888/index.html
....
Time taken for tests: 60.725 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1201378 bytes
HTML transferred: 1187850 bytes
Requests per second: 0.82 [#/sec] (mean)
Time per request: 12145.00 [ms] (mean)
Time per request: 1214.50 [ms] (mean, across all concurrent
requests)
Transfer rate: 19.78 [Kbytes/sec] received
1.2s per request (excluding warmup) is pathetic. By comparison, Apache
takes 2 MILLISECONDS to serve the same page:
Time taken for tests: 0.109 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1259594 bytes
HTML transferred: 1243754 bytes
Requests per second: 458.72 [#/sec] (mean)
Time per request: 21.80 [ms] (mean)
Time per request: 2.18 [ms] (mean, across all concurrent requests)
Transfer rate: 11555.91 [Kbytes/sec] received
Perhaps we're doing something stupid in our sitemap. Perhaps Cocoon
caching is crap. Whatever the cause, we're stuck with the result. I
consider online Forrest to be too slow for anything other than
development work.
So I'd like to narrow Forrest's potential scope to *just* those features
that can be expressed in HTML. We get the best of Cocoon (sitemap
expressivity) while leaving out the worst (performance, overhead). This
means Forrest will never evolve into some ultimate CMS, but there's
enough of those in the world already.
--Jeff
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 22, 2003 at 06:21:12AM -0600, Antonio Gallardo wrote:
...
> >> > - 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?
That's how I saw it working. Search on or off. If on, google or lucene:
<enable-search>true</enable-search>
<search-type>lucene|google</search-type>
> 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.
Lucene search is great feature, and I'm keen to see it in Forrest once
the bug that causes it to break offline sites' builds is fixed.
> >> 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.
+1
--Jeff
...
> Best Regards,
>
> Antonio Gallardo
>
>
>
Re: Forrest: dynamic or static?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
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
docs?
>> > - 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:
http://xml.apache.org/forrest/index.html#Static+or+Dynamic
>> >For especially useful features, like searching, we can bend the rule
>> and have online/offline equivalents (lucene and google).
+1
> 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.
+1
Best Regards,
Antonio Gallardo
Re: Forrest: dynamic or static?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
...
> 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.
This is what we have been doing till now, so I can't see the problem,
except for the latest stuff.
Instead of continuing on this thread, I'd suggest we call for a vote on
these items.
As I said, the XSP thing simply will vanish with blocks, and we just
have to prepare every "dynamic" feature with a CLI equivalent. For
example, catering for users that have HTTPD installed and using it's
capabilities can be a nice "CLI" complement to the Cocoon dynamic features.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
>
> Okay, say I want to produce a site that has both English and German
> contents, like jakarta-poi. I need a set of English pages with an
> English menu, and German pages with a German menu. How does the current
> i18n support help us towards that goal?
>
I have not fully investigate, but out of the accept string or CGI
parameter you can specify locale, only if these fail the server locale
will be used.
So you can specify the locale and save these files either on one
directory per locale or on the name of the file.
>
>>>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?
pure content that needs to be threated.
>
>
>>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.
>
There was a vote and that was even. But you remove two days ago so I
will write up a document and call a vote.
>
>>>- Lucene integration. As it exists in CVS, it screws up statically
>>> rendered sites, so is disabled.
>>>
>>
>>Hold on here... The idea was to be disabled by default, This needs more
>>investigation.
>
>
> Please do.
>
>
>>>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.
>>>
>>>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.
>>
>>The fact that there is a bug does not mean that we need to change our
>>strategy.
>
>
> The bug is irrelevant to this thread.
>
which bug? I was tallikg about the problem with lucene, that is relevant
for this thread.
> Read what I wrote:
>
> "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**."
>
> 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.
>
If we follow that rule we have to remove Lucene.
That is why I am against forrest being as replacement of Norman Walsh
sdocbook style sheets.
Cheers,
Cheche
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 22, 2003 at 12:25:49PM +0200, Juan Jose Pablos wrote:
> Jeff Turner wrote:
> >I see we now have i18n'ed menus, where the language is chosen based on
> >the locale of the requester.
> >
> >This feature is useless if you're rendering a static site with the CLI.
> >The requester's locale will be that of the local machine.
> >
>
> That is not true!
Okay, say I want to produce a site that has both English and German
contents, like jakarta-poi. I need a set of English pages with an
English menu, and German pages with a German menu. How does the current
i18n support help us towards that goal?
> >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.
> > - Lucene integration. As it exists in CVS, it screws up statically
> > rendered sites, so is disabled.
> >
>
> Hold on here... The idea was to be disabled by default, This needs more
> investigation.
Please do.
> >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.
> >
> >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.
>
> The fact that there is a bug does not mean that we need to change our
> strategy.
The bug is irrelevant to this thread.
> >For especially useful features, like searching, we can bend the rule and
> >have online/offline equivalents (lucene and google).
> >
>
> -1 The fact that some features can be done only in live mode does not
> mean that we need to restict ourselves.
>
>
> >I can demonstrate why I take such a hardline stance with a small
> >benchmark:
> >
>
> Sure, but did you took in account how long took a whole web site to be
> render?, so If I made a modification, I need to wait more than 0.2
> seconds to see the results.
Read what I wrote:
"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**."
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.
--Jeff
...
>
> Cheers,
> Cheche
>
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Jeff Turner wrote:
> I see we now have i18n'ed menus, where the language is chosen based on
> the locale of the requester.
>
> This feature is useless if you're rendering a static site with the CLI.
> The requester's locale will be that of the local machine.
>
That is not true!
> 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. Plus this was
requested by users!
> - Lucene integration. As it exists in CVS, it screws up statically
> rendered sites, so is disabled.
>
Hold on here... The idea was to be disabled by default, This needs more
investigation.
>
> 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.
>
> 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.
The fact that there is a bug does not mean that we need to change our
strategy.
> For especially useful features, like searching, we can bend the rule and
> have online/offline equivalents (lucene and google).
>
-1 The fact that some features can be done only in live mode does not
mean that we need to restict ourselves.
> I can demonstrate why I take such a hardline stance with a small
> benchmark:
>
Sure, but did you took in account how long took a whole web site to be
render?, so If I made a modification, I need to wait more than 0.2
seconds to see the results.
>
> Perhaps we're doing something stupid in our sitemap. Perhaps Cocoon
> caching is crap. Whatever the cause, we're stuck with the result. I
> consider online Forrest to be too slow for anything other than
> development work.
I think that we have a problem with SVG. Whatever we do stupid on our
sitemap will affect the render of offline generation. So we need to look
into this issue as well.
>
> So I'd like to narrow Forrest's potential scope to *just* those features
> that can be expressed in HTML. We get the best of Cocoon (sitemap
> expressivity) while leaving out the worst (performance, overhead). This
> means Forrest will never evolve into some ultimate CMS, but there's
> enough of those in the world already.
-1 I would like to see both online or offline mode work, I have not
seen any reason of why can not be achived, so I stick to that.
I like forrest to be focus on features needed by an small web site, but
that does not mean to be some ultimate CMS.
Cheers,
Cheche
Re: Forrest: dynamic or static?
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeff Turner wrote:
<snip/>
> 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.
<snip/>
>
> 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.
> For especially useful features, like searching, we can bend the rule and
> have online/offline equivalents (lucene and google).
<snip/>
Definitely +1. We should clearly express that line in our documentation.
This reminds us of the "scope" discussions that we had a while ago.
--David
Re: Forrest: dynamic or static?
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> 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.
+1
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Konstantin Piroumian wrote:
>From: "Jeff Turner" <je...@apache.org>
>
>
>
>>I see we now have i18n'ed menus, where the language is chosen based on
>>the locale of the requester.
>>
>>This feature is useless if you're rendering a static site with the CLI.
>>The requester's locale will be that of the local machine.
>>
>>
>
>What if we add links like <a href="?locale=de">German</a> to each page?
>Won't Cocoon generate according i18n-ized pages?
>
>Not sure if Cocoon CLI processes request parameters, but maybe it can be
>extended to generate pages with them, e.g.:
>
>request: index.htm?locale=de&page=1
>result: index.htm$locale=de&page=1 (it's a legal name for Win2K)
>
>
Though I've never tested it, the code is in place (and always has been)
for the CLI to handle request parameters and to merge them into the
filename.
>Another option is to generate content separately for each language (by
>setting the current locale in config or specifing in command line) then
>placing them in different directories and here Apache HTTPD can be used to
>redirect requests depending on users locale.
>
>
Sounds like quite a sexy feature.
Regards, Upayavira
Re: Forrest: dynamic or static?
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeff Turner" <je...@apache.org>
> I see we now have i18n'ed menus, where the language is chosen based on
> the locale of the requester.
>
> This feature is useless if you're rendering a static site with the CLI.
> The requester's locale will be that of the local machine.
What if we add links like <a href="?locale=de">German</a> to each page?
Won't Cocoon generate according i18n-ized pages?
Not sure if Cocoon CLI processes request parameters, but maybe it can be
extended to generate pages with them, e.g.:
request: index.htm?locale=de&page=1
result: index.htm$locale=de&page=1 (it's a legal name for Win2K)
Another option is to generate content separately for each language (by
setting the current locale in config or specifing in command line) then
placing them in different directories and here Apache HTTPD can be used to
redirect requests depending on users locale.
<snip />
-- Konstantin
>
> --Jeff
>
>
Re: Forrest: dynamic or static?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Nicola Ken Barozzi dijo:
> Jeff Turner wrote:
> ...
>> 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.
>
> May I disagree?
> IMO limiting the scope too much does not bring benefits.
>
>> 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. For especially useful features, like searching, we can
>> bend the rule and have online/offline equivalents (lucene and google).
>
> Let me bend this a bit.
>
> Forrest should be targetted *mainly* as an offline feneration tool,
> making it possible to use almost all features even without a live Cocoon
> running.
>
> But this doesn't mean that we should in any way forget about those that
> use it live and not cater for them in any way.
>
>> I can demonstrate why I take such a hardline stance with a small
>> benchmark:
> ...
>> 1.2s per request (excluding warmup) is pathetic. By comparison,
>> Apache takes 2 MILLISECONDS to serve the same page:
> ...
>> Perhaps we're doing something stupid in our sitemap. Perhaps Cocoon
>> caching is crap. Whatever the cause, we're stuck with the result. I
>> consider online Forrest to be too slow for anything other than
>> development work.
>
> For now, it surely is. Never say never.
>
>> So I'd like to narrow Forrest's potential scope to *just* those
>> features that can be expressed in HTML. We get the best of Cocoon
>> (sitemap expressivity) while leaving out the worst (performance,
>> overhead). This means Forrest will never evolve into some ultimate
>> CMS, but there's enough of those in the world already.
>
> Lenya is a CMS, and there is no need to reinvent it. You have deleted
> the pathetic editor attempts I had put in CVS, and I did not say
> anything about it, because I agree that Forrest must remain focused.
>
> So +1 to keep an eye to "static" and "Apache-friendly" Forrest.
> -1 to crippling its ability to do the same in "live" mode, as that's how
> most intranets use it.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: Forrest: dynamic or static?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
...
> What I'm against adding are features that perhaps 5% of Forrest users
> want, that require a live Cocoon. Looking in the Cocoon samples, there
> are *hundreds* of features falling in this category. We need to have
> some guidelines or Forrest will end up a bloated mess, trying to be
> everything to everyone.
+1
I had thought that we wanted to just forget any online use, such as
removing the webapp target and such.
This is exactly what I mean too.
...
>>Lenya is a CMS, and there is no need to reinvent it. You have deleted
>>the pathetic editor attempts I had put in CVS, and I did not say
>>anything about it, because I agree that Forrest must remain focused.
>
> Cool. Actually at the time I had no thoughts of "focus". The editor was
> just broken and unmaintained.
It was not finished. Nobody stepped up for collaborating on it, so I
gathered that there was no interest in it either, so I stopped myself on it.
>>So +1 to keep an eye to "static" and "Apache-friendly" Forrest.
>>-1 to crippling its ability to do the same in "live" mode, as that's how
>>most intranets use it.
>
> ..and how people use it to develop pages, so of course.
Of course.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 22, 2003 at 09:49:40AM +0200, Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> ...
> >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.
>
> May I disagree?
Certainly, if you back it up :)
> IMO limiting the scope too much does not bring benefits.
>
> >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.
> >For especially useful features, like searching, we can bend the rule and
> >have online/offline equivalents (lucene and google).
>
> Let me bend this a bit.
>
> Forrest should be targetted *mainly* as an offline feneration tool,
> making it possible to use almost all features even without a live Cocoon
> running.
"mainly".. "almost all".. weasel words! :) It's better to take the risk
of being wrong than hedge every sentence like a politician..
> But this doesn't mean that we should in any way forget about those that
> use it live and not cater for them in any way.
We don't cater for them in any way currently. As of 0.5, Forrest has no
features that rely on it being online. Certainly if there's online
features that would benefit most of our users (like searching), we can
consider adding it.
What I'm against adding are features that perhaps 5% of Forrest users
want, that require a live Cocoon. Looking in the Cocoon samples, there
are *hundreds* of features falling in this category. We need to have
some guidelines or Forrest will end up a bloated mess, trying to be
everything to everyone.
> >I can demonstrate why I take such a hardline stance with a small
> >benchmark:
> ...
> >1.2s per request (excluding warmup) is pathetic. By comparison, Apache
> >takes 2 MILLISECONDS to serve the same page:
> ...
> >Perhaps we're doing something stupid in our sitemap. Perhaps Cocoon
> >caching is crap. Whatever the cause, we're stuck with the result. I
> >consider online Forrest to be too slow for anything other than
> >development work.
>
> For now, it surely is. Never say never.
>
> >So I'd like to narrow Forrest's potential scope to *just* those features
> >that can be expressed in HTML. We get the best of Cocoon (sitemap
> >expressivity) while leaving out the worst (performance, overhead). This
> >means Forrest will never evolve into some ultimate CMS, but there's
> >enough of those in the world already.
>
> Lenya is a CMS, and there is no need to reinvent it. You have deleted
> the pathetic editor attempts I had put in CVS, and I did not say
> anything about it, because I agree that Forrest must remain focused.
Cool. Actually at the time I had no thoughts of "focus". The editor was
just broken and unmaintained.
> So +1 to keep an eye to "static" and "Apache-friendly" Forrest.
> -1 to crippling its ability to do the same in "live" mode, as that's how
> most intranets use it.
..and how people use it to develop pages, so of course.
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
Re: Forrest: dynamic or static?
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> So +1 to keep an eye to "static" and "Apache-friendly" Forrest.
> -1 to crippling its ability to do the same in "live" mode, as that's how
> most intranets use it.
I beg to differ: at our customer installations, we have been using
static generation for intranet sites. It makes tracking Forrest upgrades
a bit more robust. We added a script to the cvs check-in procedure,
touching a 'cvsisdirty' file, which is then checked by a cron job to see
whether it needs to regenerate the static rendition. The cron job runs
very often (every 15 minutes IIRC), but only starts Forrest when the
cvsisdirty file is there (and cleans up that file after the Forrest
run). That way, we have near-instantaneous rendering of static files,
which can be made searchable with htDig.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Forrest: dynamic or static?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
...
> 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.
May I disagree?
IMO limiting the scope too much does not bring benefits.
> 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.
> For especially useful features, like searching, we can bend the rule and
> have online/offline equivalents (lucene and google).
Let me bend this a bit.
Forrest should be targetted *mainly* as an offline feneration tool,
making it possible to use almost all features even without a live Cocoon
running.
But this doesn't mean that we should in any way forget about those that
use it live and not cater for them in any way.
> I can demonstrate why I take such a hardline stance with a small
> benchmark:
...
> 1.2s per request (excluding warmup) is pathetic. By comparison, Apache
> takes 2 MILLISECONDS to serve the same page:
...
> Perhaps we're doing something stupid in our sitemap. Perhaps Cocoon
> caching is crap. Whatever the cause, we're stuck with the result. I
> consider online Forrest to be too slow for anything other than
> development work.
For now, it surely is. Never say never.
> So I'd like to narrow Forrest's potential scope to *just* those features
> that can be expressed in HTML. We get the best of Cocoon (sitemap
> expressivity) while leaving out the worst (performance, overhead). This
> means Forrest will never evolve into some ultimate CMS, but there's
> enough of those in the world already.
Lenya is a CMS, and there is no need to reinvent it. You have deleted
the pathetic editor attempts I had put in CVS, and I did not say
anything about it, because I agree that Forrest must remain focused.
So +1 to keep an eye to "static" and "Apache-friendly" Forrest.
-1 to crippling its ability to do the same in "live" mode, as that's how
most intranets use it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Jeff Turner wrote:
>On Sun, Sep 21, 2003 at 07:20:19AM +0200, Sebastian Bergmann wrote:
>
>
>>Jeff Turner wrote:
>>
>>
>>>We could have "skins" that:
>>>
>>> - Generate PHP instead of HTML
>>>
>>>
>> This sounds interesting and maybe, if my time allows it, I can help
>> with this.
>>
>>
>
>I'm pretty PHP-ignorant. What kind of things would outputting .php files
>allow?
>
>All a bit academic currently, as I've yet to succeed in getting Forrest
>to generate files with a .php (or .shtml) extension.
>
>--Jeff
>
>
I think the way to think of it is this:
If Forrest is about building static sites, then there's certain
functionality that one won't have (that we would have if deployed as a
webapp). However, those sites are to be deployed on a web server, and
most web servers have some dynamic capabilities these days - so why not
use it, to regain some of that lost functionality.
So, whether it's modrewrite, or PHP, or ASP, or whatever, you can use
this dynamic functionality to handle internationalisation, error pages,
simple site search engines, etc, etc, all of which supports the static
site that you're presenting.
It is not going to be possible to be web server agnostic, as each server
offers different technologies. But it does make sense to support a
range, or at least encourage others to implement features on a range of
servers.
Hope that all makes sense. With this functionailty, I could actually see
myself using Forrest! (I have a largely static site, served by Cocoon,
but I need Cocoon for search and some backend edititng).
Regards, Upayavira
Re: Forrest: dynamic or static?
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Jeff Turner wrote:
> What kind of things would outputting .php files allow?
I have not yet given this much thought, yet, I only found the general
idea interesting.
One thing I would use this for would probably be pulling an RSS feed
and integrating it into the site.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Sun, Sep 21, 2003 at 07:20:19AM +0200, Sebastian Bergmann wrote:
> Jeff Turner wrote:
> > We could have "skins" that:
> >
> > - Generate PHP instead of HTML
>
> This sounds interesting and maybe, if my time allows it, I can help
> with this.
I'm pretty PHP-ignorant. What kind of things would outputting .php files
allow?
All a bit academic currently, as I've yet to succeed in getting Forrest
to generate files with a .php (or .shtml) extension.
--Jeff
> --
> Sebastian Bergmann
> http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
> Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
>
Re: Forrest: dynamic or static?
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Jeff Turner wrote:
> We could have "skins" that:
>
> - Generate PHP instead of HTML
This sounds interesting and maybe, if my time allows it, I can help
with this.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Sat, Sep 20, 2003 at 07:17:44PM +0200, Stefano Mazzocchi wrote:
...
> May I suggest something wild? Years ago, thinking about exactly these
> requirements, I tought that some of the apache magic could be
> pre-generated by forrect in .htaccess files.
>
> I know that, historically, people coming from the web java world know
> nothing (or very little) about HTTPD features, but there are tons of
> features in apache that could be used to "symulate" the behavior that
> dynamic forrest does, in a completely transparent way.
>
> It sounded silly to me at first too: Forrest that generates mod_rewrite
> instructions?
>
> But think about it: save the i18n pages as index.en.html and apache
> does the language redirection for you. why not use it?
>
> mod_rewrite could be used for tons of things. mod_rewtire it's woodoo,
> admittedly, and this is the reason why nobody wants to touch it with a
> stick, but if the mod_rewrite conf files were generated by forrest,
> people would get speed and functionality without having to learn
> mod_rewrite or to throw away the nice forrest features. It would be the
> best of both worlds.
>
> worth considering, IMO.
Certainly. We have separation of content from presentation, so we
shouldn't be afraid of doing cool stuff like this. Just requires some
expansion of the definition of a "Forrest skin".
We could have "skins" that:
- Output httpd-specific stuff
- Generate PHP instead of HTML
- Generate an expanded webapp with servlets (lucene) in WEB-INF/classes
...
The investment in SoC finally pays off.
--Jeff
> --
> Stefano.
>
Re: Forrest: dynamic or static?
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Stefano Mazzocchi wrote:
> you need a servlet engine
Thanks for the clarification, this is what I thought. I was a bit
confused by the discussion :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Forrest: dynamic or static?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Upayavira dijo:
> Antonio Gallardo wrote:
>
>>Upayavira dijo:
>>
>>
>>>Juan Jose Pablos wrote:
>>>
>>>
>>>
>>>>Upayavira wrote:
>>>>
>>>>
>>>>
>>>>>By using the features of the web server on which the site is
>>>>>deployed. If its Apache, you could use a PHP search engine, or ASP
>>>>> on
>>>>> IIS, etc, etc, etc. If we can't use Java, use what we've got.
>>>>>There's probably plenty of decent, open source search engines
>>>>> written in PHP or ASP that could be included into Forrest.
>>>>>
>>>>>Regards, Upayavira
>>>>>
>>>>>
>>
>>No, please no. This is the way back! We are using XML, because it is
>> far better than any mixed tags (script + HTML).
>>
>>I really dont think this is a good idea.
>>
>>
> Of course using XML is better. I wouldn't be here if I didn't think so.
I know.
>
> But how do you offer (non-google) search on a (for example) Apache
> served site?
Online -> google. Don't see a reason to not use it even with Apache HTTPD.
Offline -> dont know. To do that we need a serverside search engine, maybe
htDig. But I think it just can be drafted in a How-to of Forrest. But no
to be included into Forrest.
I hope it explain my point.
Antonio Gallardo
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
>Upayavira dijo:
>
>
>>Juan Jose Pablos wrote:
>>
>>
>>
>>>Upayavira wrote:
>>>
>>>
>>>
>>>>By using the features of the web server on which the site is
>>>>deployed. If its Apache, you could use a PHP search engine, or ASP on
>>>> IIS, etc, etc, etc. If we can't use Java, use what we've got.
>>>>There's probably plenty of decent, open source search engines
>>>>written in PHP or ASP that could be included into Forrest.
>>>>
>>>>Regards, Upayavira
>>>>
>>>>
>
>No, please no. This is the way back! We are using XML, because it is far
>better than any mixed tags (script + HTML).
>
>I really dont think this is a good idea.
>
>
Of course using XML is better. I wouldn't be here if I didn't think so.
But how do you offer (non-google) search on a (for example) Apache
served site?
Regards, Upayavira
Re: Forrest: dynamic or static?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Jeff Turner dijo:
> On Mon, Sep 22, 2003 at 07:32:55AM -0600, Antonio Gallardo wrote:
>> Upayavira dijo:
>> > Juan Jose Pablos wrote:
>> >
>> >> Upayavira wrote:
>> >>
>> >>>
>> >>>
>> >>> By using the features of the web server on which the site is
>> deployed. If its Apache, you could use a PHP search engine, or ASP
>> on
>> >>> IIS, etc, etc, etc. If we can't use Java, use what we've got.
>> >>> There's probably plenty of decent, open source search engines
>> written in PHP or ASP that could be included into Forrest.
>> >>>
>> >>> Regards, Upayavira
>>
>> No, please no. This is the way back! We are using XML, because it is
>> far better than any mixed tags (script + HTML).
>>
>> I really dont think this is a good idea.
>
> But think; if we write a _skin_ that outputs PHP, CGIs, .htaccess or
> whatever crazy stuff is needed, don't we get the best of both worlds?
> Our XML is kept nice and clean, and we take advantage of native features
> of the webserver.
Well, maybe as a "package" that we does need to take care of it. Just as
some java libs we use in Forrest. Forrest devel does not take care of the
development of Java libs, we just copy the libs and use it.
BTW, this let me think in a search engine plug-in-like connector. Under
this idea we can allow people to write "connectors" for any search engine
they want. Is this a way? please comments.
Best Regards,
Antonio Gallardo.
Re: Forrest: dynamic or static?
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 22, 2003 at 07:32:55AM -0600, Antonio Gallardo wrote:
> Upayavira dijo:
> > Juan Jose Pablos wrote:
> >
> >> Upayavira wrote:
> >>
> >>>
> >>>
> >>> By using the features of the web server on which the site is
> >>> deployed. If its Apache, you could use a PHP search engine, or ASP on
> >>> IIS, etc, etc, etc. If we can't use Java, use what we've got.
> >>> There's probably plenty of decent, open source search engines
> >>> written in PHP or ASP that could be included into Forrest.
> >>>
> >>> Regards, Upayavira
>
> No, please no. This is the way back! We are using XML, because it is far
> better than any mixed tags (script + HTML).
>
> I really dont think this is a good idea.
But think; if we write a _skin_ that outputs PHP, CGIs, .htaccess or
whatever crazy stuff is needed, don't we get the best of both worlds?
Our XML is kept nice and clean, and we take advantage of native features
of the webserver.
--Jeff
> Best Regards,
>
> Antonio Gallardo.
>
>
Re: Forrest: dynamic or static?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Upayavira dijo:
> Juan Jose Pablos wrote:
>
>> Upayavira wrote:
>>
>>>
>>>
>>> By using the features of the web server on which the site is
>>> deployed. If its Apache, you could use a PHP search engine, or ASP on
>>> IIS, etc, etc, etc. If we can't use Java, use what we've got.
>>> There's probably plenty of decent, open source search engines
>>> written in PHP or ASP that could be included into Forrest.
>>>
>>> Regards, Upayavira
No, please no. This is the way back! We are using XML, because it is far
better than any mixed tags (script + HTML).
I really dont think this is a good idea.
Best Regards,
Antonio Gallardo.
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Upayavira wrote:
>
>>
>>
>> By using the features of the web server on which the site is
>> deployed. If its Apache, you could use a PHP search engine, or ASP on
>> IIS, etc, etc, etc. If we can't use Java, use what we've got. There's
>> probably plenty of decent, open source search engines written in PHP
>> or ASP that could be included into Forrest.
>>
>> Regards, Upayavira
>>
>
> All these technologies are run on the server not on the client side.
> And I would to search xml stuff, not the output (html,pdf).
Yup. But if you don't have a server that can handle searching XML (and
mapping the results onto the relevant HTML), do you have any other choice?
Regards, Upayavira
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira wrote:
>
>
> By using the features of the web server on which the site is deployed.
> If its Apache, you could use a PHP search engine, or ASP on IIS, etc,
> etc, etc. If we can't use Java, use what we've got. There's probably
> plenty of decent, open source search engines written in PHP or ASP that
> could be included into Forrest.
>
> Regards, Upayavira
>
All these technologies are run on the server not on the client side. And
I would to search xml stuff, not the output (html,pdf).
Cheche
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Stefano Mazzocchi wrote:
>
>>
>> On Monday, Sep 22, 2003, at 12:43 Europe/Rome, Juan Jose Pablos wrote:
>>
>>>
>>> you can use an applet so the search is done on the client, but I am
>>> not sure about this on large sites.
>>
>>
>>
>> and send your index everytime to the client? for every page? c'mon
>>
>
> Well, for cases where it is not access to a servlet engine, I am not
> aware of other way to achive this.
By using the features of the web server on which the site is deployed.
If its Apache, you could use a PHP search engine, or ASP on IIS, etc,
etc, etc. If we can't use Java, use what we've got. There's probably
plenty of decent, open source search engines written in PHP or ASP that
could be included into Forrest.
Regards, Upayavira
Re: Forrest: dynamic or static?
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Sep 22, 2003, at 14:38 Europe/Rome, Juan Jose Pablos wrote:
> Stefano Mazzocchi wrote:
>> On Monday, Sep 22, 2003, at 12:43 Europe/Rome, Juan Jose Pablos wrote:
>>>
>>> you can use an applet so the search is done on the client, but I am
>>> not sure about this on large sites.
>> and send your index everytime to the client? for every page? c'mon
>
> Well, for cases where it is not access to a servlet engine, I am not
> aware of other way to achive this.
how about using a non-java indexing tool? something that doesn't
require a shitload of time to start as a CGI?
java is not the only language outthere.
--
Stefano.
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Stefano Mazzocchi wrote:
>
> On Monday, Sep 22, 2003, at 12:43 Europe/Rome, Juan Jose Pablos wrote:
>>
>> you can use an applet so the search is done on the client, but I am
>> not sure about this on large sites.
>
>
> and send your index everytime to the client? for every page? c'mon
>
Well, for cases where it is not access to a servlet engine, I am not
aware of other way to achive this.
Cheche
Re: Forrest: dynamic or static?
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Sep 22, 2003, at 12:43 Europe/Rome, Juan Jose Pablos wrote:
> Stefano Mazzocchi wrote:
>> On Saturday, Sep 20, 2003, at 21:02 Europe/Rome, Sebastian Bergmann
>> wrote:
>>> Dave Brondsema wrote:
>>>
>>>> And since this is an intranet site, google searches aren't possible
>>>> and so we are very interested in using lucene.
>>>
>>>
>>> I haven't looked at Apache Lucene yet, hence this question: Is it
>>> possible to use it with Forrest in non-WebApp-mode?
>> at the very minimum, you need a servlet engine on the side since
>> calling a JVM thru CGI sounds like a pretty silly things to do
>> indeed, unless you want your search to take something like a few
>> minutes ;-)
>> --
>> Stefano.
>
> you can use an applet so the search is done on the client, but I am
> not sure about this on large sites.
and send your index everytime to the client? for every page? c'mon
--
Stefano.
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Stefano Mazzocchi wrote:
>
> On Saturday, Sep 20, 2003, at 21:02 Europe/Rome, Sebastian Bergmann wrote:
>
>> Dave Brondsema wrote:
>>
>>> And since this is an intranet site, google searches aren't possible
>>> and so we are very interested in using lucene.
>>
>>
>> I haven't looked at Apache Lucene yet, hence this question: Is it
>> possible to use it with Forrest in non-WebApp-mode?
>
>
> at the very minimum, you need a servlet engine on the side since calling
> a JVM thru CGI sounds like a pretty silly things to do indeed, unless
> you want your search to take something like a few minutes ;-)
>
> --
> Stefano.
you can use an applet so the search is done on the client, but I am not
sure about this on large sites.
Cheche
Re: Forrest: dynamic or static?
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Sep 20, 2003, at 21:02 Europe/Rome, Sebastian Bergmann
wrote:
> Dave Brondsema wrote:
>> And since this is an intranet site, google searches aren't possible
>> and so we are very interested in using lucene.
>
> I haven't looked at Apache Lucene yet, hence this question: Is it
> possible to use it with Forrest in non-WebApp-mode?
at the very minimum, you need a servlet engine on the side since
calling a JVM thru CGI sounds like a pretty silly things to do indeed,
unless you want your search to take something like a few minutes ;-)
--
Stefano.
Re: Forrest: dynamic or static?
Posted by Sebastian Bergmann <sb...@sebastian-bergmann.de>.
Dave Brondsema wrote:
> And since this is an intranet site, google searches aren't possible
> and so we are very interested in using lucene.
I haven't looked at Apache Lucene yet, hence this question: Is it
possible to use it with Forrest in non-WebApp-mode?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Re: Forrest: dynamic or static?
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Stefano Mazzocchi <st...@apache.org>:
>
> On Saturday, Sep 20, 2003, at 15:44 Europe/Rome, Jeff Turner wrote:
>
> > 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.
> > For especially useful features, like searching, we can bend the rule
> > and
> > have online/offline equivalents (lucene and google).
>
> +1
>
> May I suggest something wild? ... Forrest that generates mod_rewrite
> instructions? ...
>
Not everyone uses apache. For example, we have a corporate intranet site that
uses Weblogic to host the site because that's what we use everywhere else. But
we deploy a webapp of statically generated forrest files, not a "live" webapp.
And since this is an intranet site, google searches aren't possible and so we
are very interested in using lucene.
Obviously forrest can't be designed to support any and all possible
environments, but nobody should forget the world outside of apache & tomcat.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Upayavira wrote:
>
>>
>> If you're happy to have a directory tree for each language (as
>> opposed to index.en.html, and index.de.html), then you could do this
>> really easy with minimal modification to the CLI.
>>
>
> But I thought that you could use the <accept/> tag.
No idea. Never done internationalisation. If accept is okay, that would
be file. But with the existing CLI, you can only have one accepts entry
per xconf, rather than per URI (or group of URIs). Again, minimal code
change to make it possible to associate an accept header with a group of
URIs.
>> All you need is a way specify the locale for a URI listed in the
>> cli.xconf. I reckon that'd take me 15 minutes. Then you could say:
>>
>> <uri src="index.html" locale="en/gb" dest="site/en/"/>
>> <uri src="index.html" locale="de" dest="site/de/"/>
>> etc.
>> I'd extend the CommandLineRequest class to return your specified
>> locale instead of the default.
>>
>> Then you've just got to create some Apache rewriting rules, and
>> you're away.
>>
>
> I will check Apache documentation, to findout the best approach.
I'm curious...
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Upayavira wrote:
>
> If you're happy to have a directory tree for each language (as opposed
> to index.en.html, and index.de.html), then you could do this really easy
> with minimal modification to the CLI.
>
But I thought that you could use the <accept/> tag.
> All you need is a way specify the locale for a URI listed in the
> cli.xconf. I reckon that'd take me 15 minutes. Then you could say:
>
> <uri src="index.html" locale="en/gb" dest="site/en/"/>
> <uri src="index.html" locale="de" dest="site/de/"/>
> etc.
> I'd extend the CommandLineRequest class to return your specified locale
> instead of the default.
>
> Then you've just got to create some Apache rewriting rules, and you're
> away.
>
I will check Apache documentation, to findout the best approach.
Cheers,
cheche
Re: Forrest: dynamic or static?
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Stefano Mazzocchi wrote:
>
>> But think about it: save the i18n pages as index.en.html and apache
>> does the language redirection for you. why not use it?
>
>
>
> I do not think that this idea is wild, This is more or less the idea I
> have in mind, but i have not got the time to get it working yet.
>
> But this stuff is from mod_negotiation module.
Hmm,
If you're happy to have a directory tree for each language (as opposed
to index.en.html, and index.de.html), then you could do this really easy
with minimal modification to the CLI.
All you need is a way specify the locale for a URI listed in the
cli.xconf. I reckon that'd take me 15 minutes. Then you could say:
<uri src="index.html" locale="en/gb" dest="site/en/"/>
<uri src="index.html" locale="de" dest="site/de/"/>
etc.
I'd extend the CommandLineRequest class to return your specified locale
instead of the default.
Then you've just got to create some Apache rewriting rules, and you're away.
Let me know if you want this.
Regards, Upayavira
>
> Cheers,
> Cheche
>
>
Re: Forrest: dynamic or static?
Posted by Juan Jose Pablos <ch...@che-che.com>.
Stefano Mazzocchi wrote:
> But think about it: save the i18n pages as index.en.html and apache does
> the language redirection for you. why not use it?
I do not think that this idea is wild, This is more or less the idea I
have in mind, but i have not got the time to get it working yet.
But this stuff is from mod_negotiation module.
Cheers,
Cheche
Re: Forrest: dynamic or static?
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Sep 20, 2003, at 15:44 Europe/Rome, Jeff Turner wrote:
> I see we now have i18n'ed menus, where the language is chosen based on
> the locale of the requester.
>
> This feature is useless if you're rendering a static site with the CLI.
> The requester's locale will be that of the local machine.
>
> Then we have:
>
> - The addition of XSP. Lots of uses with dynamic Forrest, none (that
> I
> know of) for a statically rendered site.
> - Lucene integration. As it exists in CVS, it screws up statically
> rendered sites, so is disabled.
>
>
> 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.
Yes, good call.
> 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.
> For especially useful features, like searching, we can bend the rule
> and
> have online/offline equivalents (lucene and google).
+1
May I suggest something wild? Years ago, thinking about exactly these
requirements, I tought that some of the apache magic could be
pre-generated by forrect in .htaccess files.
I know that, historically, people coming from the web java world know
nothing (or very little) about HTTPD features, but there are tons of
features in apache that could be used to "symulate" the behavior that
dynamic forrest does, in a completely transparent way.
It sounded silly to me at first too: Forrest that generates mod_rewrite
instructions?
But think about it: save the i18n pages as index.en.html and apache
does the language redirection for you. why not use it?
mod_rewrite could be used for tons of things. mod_rewtire it's woodoo,
admittedly, and this is the reason why nobody wants to touch it with a
stick, but if the mod_rewrite conf files were generated by forrest,
people would get speed and functionality without having to learn
mod_rewrite or to throw away the nice forrest features. It would be the
best of both worlds.
worth considering, IMO.
--
Stefano.