Robert Goene wrote:
Andreas Hartmann wrote:
Robert Goene wrote:
I want to use the LuceneIndexTransformer to update the lucene index
when a page is published. This transformer does provide exactly the
functions i need for 'incremental' and 'configurable' indexing possible.
Maybe it is possible to use this transformer from the usecase handler
itself, is it?
This would be a quite bad design. Generally, a transformer should not
be used for this purpose. Rather extract the index update functionality
in a separate service which you access from the usecase handler.
The transformer does exactly the job it requires to do. It makes the
configurable indexing of pages a very easy job. With the use of a xslt
sheet, one can select the fields that must be indexed.
You're right, after reading some more docs I agree that the
LuceneIndexTransformer could be used quite efficiently in the following way:
- declare the pipeline in search/usecase.xmap
- use the CInclude functionality of the usecase framework to include
the output (status page) of the pipeline in the JX template
For an example, see the admin.serverStatus usecase.
A drawback of this approach is that we have to rely on the error
handling capabilities of the LucIndTransformer and can't apply the usecase
framework error handling facilities. Another drawback is that it can't be
executed from within other usecases (like publishing).
To avoid these drawbacks, use the SourceResolver to call the LIT pipeline.
But then you have to parse the output and pass it to the JX template as
usecase parameters. Anyway, this is the preferrable approach due to the
above reasons.
Bad design would also be reimplementing an already existing and
established piece of code, especially when it meets the requirements of
my project (lenya-search SoC).
Of course it should not be re-implemented, but extracted into a
separate component. That would require discussion in the Cocoon community.
I do agree that calling a usecase from the usecase handler is not
pretty.
It would be nicer to separate the the actual service from the usecase
and call this service from another usecase, but that can be refactored
later on.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
