incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe <>
Subject Re: 2 or more component services for the same interface
Date Thu, 20 Jan 2005 22:22:12 GMT
David Sean Taylor wrote:

> Christophe wrote:
>> David Sean Taylor wrote:
>>> Christophe wrote:
>>>> David Sean Taylor wrote:
>>>> Do you need indexing & searching ? if yes, I want to make a 
>>>> proposal for an event handler which can be used to index, notify, 
>>>> .... I think AOP can help.
>>> Yes.
>>> I have a Lucene index here that I've created.
>>> Would like to adapt Graffito over it somehow
>>> I plan to start on that next week
>> That's the good time to speak about how to index the document in 
>> Graffito. I also need this feature. What do think about a event 
>> handler service  and use AOP for that ?
> Well I know I will need an API that says search(searchString)
> Lucene has its own syntax so I guess we should have a pass-thru search 
> string as well as a normalized model
I defined a criteria class which is similar to the OJB criteria + the 
possibility to make a full text search with tools like Lucene.

> As for the event handlers, what events will we be handling?

All you want depending on your needs. I'm thinking mainly about the cms 
object lifecycle (insert, delete, update, move a cms object can trigger 
an event to do something) .
It it similar to a DB table trigger.

> COuld you iterate thru the use cases for events?
When you add,delete or update a cms object you need to revisit the 
index. The first idea is to call the index service in the corresponding 
Another idea is to send an event to the event handler service which 
delegates the job to some listeners. one listener can manage the content 
index, other listeners can be used for other purposes like replications ...
It is a good way to add flexible pre & post processing on important methods.

here is a sample xml file used to add some listeners in the event 
handler service :

    <listener classname="org.apache.portals.graffito.listener.Indexer" 
synchronous="false" uri="/myojbserver/myfolder  />
synchronous="false" uri="/anotherserver/cv  />

The pamater uri can defined which part of the content tree is managed by 
the listener. Some content store like Slide supports indexing. So, it is 
not necessary to index all documents found in all content servers. This 
parameter uri becomes usefull to limit the listener scope.

Of course, we can use the Spring assembly script to register all listeners.

View raw message