forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] Search engines
Date Tue, 05 Oct 2004 11:05:26 GMT
thorsten wrote:
> David Crossley wrote:
> 
>> thorsten wrote:
>> <snip/>
>>
>>> *How it should work*
>>> We need the following components:
>>> I) site.xml - Here we can add the hooks for each site which search 
>>> engine should be used. e.g.
>>> <todo label="Todo" href="todo.html" description="Todo List" 
>>> searchType="os" searchEngine="all"/>
>>> This would offer the *all* search engines from the categorie *os*.
>>> <todo label="Todo" href="todo.html" description="Todo List" 
>>> searchType="os" searchEngine="marc, eyebrowse"/>
>>> This would offer the marc and the eyebrowse search engines from the 
>>> categorie *os*.
>>
>>
>> <snip/>
>>
>> Is this starting to overload the site.xml
>> Perhaps there are other other ways.
>>
> 
> IMO that would not be as bad. The site.xml is the one part of forrest 
> that the user really has to edit to add new content. All other files can 
> be set to default.
> 
> Anyway that leads me to the approach that Ross uses for his sourceforge 
> project. He uses manifest to extract tab and site.xml. He can edit the 
> site with a GUI. IMO we need such a think very fast.

The manifest stuff is the example plugin currently in the 
sitemap-plugins branch 
(http://svn.apache.org/viewcvs.cgi/forrest/branches/sitemap-plugins/?root=Apache-SVN). 
The GUI portion is part of the Burrokeet project 
(http://sourceforge.net/projects/burrokeet/), whether this stays a 
separate project or gets donated to some other project can be visited 
when it is a little more mature.

> ...or I have to really start the integration of forrest into lenya (et. 
> al.). Then the user will not have to edit XML docs directly but through 
> Bitflux, Kupu, et. al..

I have this second on my todo list at the moment. My plan of action 
(which has not been discussed yet) is to integrate Lenya into Burrokeet, 
which already has Forrest integrated through the Eclipse plugin in our 
scratchpad here. I plan to do the same with Lenya. In the first instance 
there will be two apps running (Forrest + Lenya), but I would hope to 
bring the two together into a single app using the sitemap-plugins branch.

What we will then have is Burrokeet (Content Structure and config 
editing), Lenya (workflow management and document editing) and Forrest 
(content publishing).  So, with respect to this RT, I would see the 
management of search engines etc. being a part of the functionality of 
Burrokeet. What this means, at least to me, is that we don't need to 
worry too much about how easy it is to edit Forrests files by hand. We 
should focus on a good clean design and really make use of Cocoon's 
excellent cacheing facilities when generating the intermediate formats 
that Forrest requires. That is, the core of Forrest is starting to get 
quite complex within itself, the idea of editing these files by hand is 
still acceptable but with more and more features being added, like the 
search facilities Thosten is proposing, this editing is going to get 
more complex.

We therefore have to decide what Forrest is intending to achieve, is it 
going to provide easily edited "intermediate" files, or is it to create 
efficient intermediate files that give us the maximum flexibility and 
performance in the source -> intermediate -> publish process.

For me we have to go for flexibility and extendability in the 
intermediate formats. We can look at ease of editing at the source stage 
and is therefore out of the scope of the Forrest project (unless we want 
to bring Burrokeet and any similar source editing projects into Forrest 
itself).

Having said that, I don't know where these Search configuration files 
should be, I'm just saying that personally I am not scared of a loss of 
human readability at the the expense of increased flexibility. So, where 
should these config files be?

Ross

Mime
View raw message