On 9/19/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
...1) it shouldn't be /select/html ... select/xslt or something, but there's no reason to assume the output of the XSLT would be html..
Right, and as Yonik suggests it probably makes more sense to create a new QueryResponseWriter for this. The Content-Type can then be selected by a request parameter, with text/html as the default?
...but is there anyway to let people add web.xml for things like ServletFilters without manully unpacking and modifyng hte war?..
The way we handle that in Cocoon 2.1.x is with ant tasks which patch web.xml (and other similar things) at build time, based on options coming from properties files. The default build properties are stored in Subversion, and user-specified build properties can override these, coming from a file that is ignored by Subversion, to select options. This works well, but the build becomes a bit messy with many options. Anyway, if server-side XSLT becomes a QueryResponseWriter, this won't be needed right now.
...if there is, we should look into it for stuff like this, and now is a good time to start...
The first step might be to create a "contrib" source directory for that kind of stuff, compile that into a separate jar that is optionally included in the generated war, based on build-time properties?
...if not, then we need to be cautious about not bloating Solr -- but the functionality of this patch seems to be worthwhile...
100% agreed on not bloating Solr, its beauty is that it does one thing and one thing well. That being said, I need to make it easier to build a self-contained demo (including user-specified search forms and HTML-formatted results) for my current project - I'll work on that and submit patches which can be refined once an add-on mechanism is in place. -Bertrand
