This is a comment about plugins in general. You can have multiple levels of plugin specificity, application-specific, company-specific, domain-specific, not-specific-at-all-aka-generic. So very common plugins can be found on the internet (hopefully), and very application-specific plugins are written by yourself or your development team.Hi Matthijs,
I think your rules-related extension to Digester is very similar to the digester "plugins" module. Would you mind reading the javadoc for the "plugins" package, and then explaining a little more about the differences between that and your code? I have placed a copy of the package-summary for plugins from the CVS head here: http://www.apache.org/~skitching/digester-plugins-package-summary.html
I didn't quite understand the following paragraph. Could you explain a
little more?
We have written a set of RuleSets that can be plugged into a digester
object when needed, so that we can have a repository of often used RuleSets and per-application custom RuleSets.
Hello Simon,The feature of being able to have the new parsing rules embedded in the document being parsed, rather than in a separate xmlrules file, isn't currently supported by the plugins module, but I don't think it would be too hard to add to that framework.
If you were willing to integrate your code with the existing plugins code, and the result wasn't too large in size, I would be interested in seeing it integrated into Digester. Even if you aren't interested in that, any feedback about the features of the existing "plugins" module vs your requirements would be appreciated.
The bit regarding the ConfigDigester seems more application-specific to me, and in my opinion less suitable for inclusion in digester core. But others on this list may well have a different opinion.
By the way, the convention on most email lists (and definitely on this one) is to reply using "bottom-posting", where your comments are placed *beneath* the earlier ones. It makes it much easier to understand an email conversation when the email can be read top-to-bottom.
Regards,
Simon
Sorry, about the top-posting, I shall bottom-post from now on.
There are really not too much differences between the plugin package and our classes. In our package, the 'plugins' are really just an implementation of a subinterface of the RuleSet interface. The advantage of that was that we didn't need to define an interface that specified how to load the Rules. When a new RuleSet is added, addRuleInstances is called and you can add your rules there. The pattern for which this RuleSet is applicable is set through the pattern property, that is, get/setPattern is defined in the subinterface of RuleSet that every plugin must implement. Of course you can choose to ignore the pattern property, just like you can ignore pathPrefix (in RuleLoader), although the javadoc says that you shouldn't.
The plugin system that enables the loading of RuleSets is a plugin as well because it implements the same interfaces, but there is the problem of bootstrapping which is done in the main digesting application (ConfigDigester in our case). But I reckon Digester's plugin system has to deal with this too.
Indeed, the ConfigDigester singleton having a Map of config objects, hasn't got much to do with plugins. I think it might be suitable as an application example, showing how to maintain a collection of objects after the xml file is parsed.
It is really cool to see how much our systems look like each other. Makes me feel I can play with the big guys :D
Regards,
Matthijs.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
