Hello Marius,
I would suggest to generate the schema and config, reloading every time there's a class change.
That would mean re-indexing everything right? It would take to much time.
No for most cases. A Lucene index is "just" a heap of "terms". If you change the schema in that you add a new field, the impact on the index is zero. If you rename a field, you need to reindex. If you change the type of a field (or its analyzer) then you have to reindex. If you delete a field, you leave some dirt, you'd have to reindex if you rewake this field name.
I believe that the query-expansion step, from title:x to title-en:x title-ft:x, etc… is best to be controlled early so that applications can change that somehow. In curriki, this is done with a custom query-component which uses the query-parser (with a default-field which does not exist) then rewrites the query objects (which is a fairly easy game).
That's actually what I'm currently investigating. I'll try to extend the ExtendedDismaxQParserPlugin, let it do its query parsing and then expand the query with more query objects when the "field" name matches some pattern (e.g. property_*)
I am not sure it's best practice, but as an application developer, I would enjoy if this code was in a Groovy page. paul