8 Aug
2009
8 Aug
'09
8:50 p.m.
Hi All,
When working on officeimporter document splitting feature we wanted to make
it possible to provide hooks so that the whole import process can be
customized external to the officeimporter module via a groovy class (on a
wiki page). Since we were in a little hurry, the solution we devised might
be called "hackish"; we provided the following interface which can be
implemented in groovy:
<code>
public interface OfficeImporterFilter {
void filter(String documentName, Document document);
void filter(String documentName, XDOM xdom, boolean isSplit);
String filter(String documentName, String content, boolean isSplit);
void setDocBridge(DocumentAccessBridge docBridge);
}
</code>
Now, Officeimporter application would pass a parameter into
DefaultOfficeImporter indicating the wiki page which contains the groovy
filter implementation. Then we do something like:
<code>
String groovyFilterParam = params.get("groovyFilter");
String groovyScript = docBridge.getDocumentContent(groovyFilterParam);
GroovyClassLoader gcl = new GroovyClassLoader();
OfficeImporterFilter importerFilter =
(OfficeImporterFilter) gcl.parseClass(groovyScript).newInstance();
importerFilter.setDocBridge(docBridge);
return importerFilter;
}
</code>
The purpose of setDocBridge() method is to inject the DAB into the filter so
that it can access wiki documents. Now I question myself why it is not
possible for a groovy class to access wiki documents without the DAB. This
also proves that this solution was not well planned or discussed with the
community. Another problem with the filter interface is that it does several
things. It would have been better to have three filters instead.
Now to the topic of this email; if we can allow groovy code to implement
XWiki components (if it is possible), we can make this whole thing very
simple. For an example, officeimporter application would pass the role-hint
of the component implementing a particular filter (which is a groovy
implementation) and DefaultOfficeImporter will simply lookup this component
and use it.
As for implementing this kind of a mechanism, we can follow something
similar to what we did with wiki macros. A special class
XWiki.XWikiComponent would contain fields like componentRole (String),
roleHint (String) & groovyClass(TextArea) and when a document with an object
of XWiki.WikiComponent is saved, we can register a new component against the
CM.
This idea was suggested to me by vincent & I thought it's time to start a
discussion about this to see what others think. Although I have few unclear
points (like how dependency injection would work), I think it would be a
handy tool to have.
Thanks in advance for your comments & suggestions :)
- Asiri
PS: OfficeImporter code has been polluted a lot because I have stuffed a lot
of features into it without properly designing them. I will be refactoring
officeimporter a little by little in coming days (as time permits).