|
From: Martin K. <Mar...@St...> - 2005-02-23 15:00:18
|
Hi there,
since I am tackling the XmlBeanDefinitionParser implementation,
I found a simple solution to add contributional support to the Spring
framework, without breaking any backward compatibility on either
library nor dtd.
First of all I refactored the parser code and gained a very deep
understanding, about what actual happends on startup.
I also done a short analysation of the world part under discurse
and discovered that a contribution is nothing other
then a bean (specialisation of it). The concept the word
bean stands for covers contributional beans also. So my simple
solution will feel natural for any user of Spring (no new concept
to be introduced, just an additional way to use beans).
Bean: A instance (singleton or not etc.)
BeanDefinition: A bean definition describes requirements toward
a bean instance.
Contribution: Contribution of feature implementations
towards a certain extension point representable by a
bean.
ExtensionPoint: The extension point is the point of extention.
Extending can be done by contributing a
contribution.
ExtensionPointPolicy: Describes the requirements for a contribution
extending the extension point. (Compatibility,
Correctness)
ExtensionPoint Stakeholder: Controls the extension point requirements
and usage. (Declaration of the extension point and
its
requirements -> Declaration, Compatibility,
Lifecycle handling)
So how does this analysation fit within the way of Spring?
Push ability (wiring up beans)
<beans>
<bean id="name"> stuff</bean>
</beans>
Contribution: (pulling feature contributions on runtime)
<beans>
<contributions extension-point="extensionPoint">
<bean notNamed>stuff</bean>
</contributions>
</beans>
Usage:
Object contributions=
ApplicationContext.getContributions(
ExtensionPoint, ExtensionPointPolicy);
I guess this would be a great feature for the spring-framework.
It would combine the world of Spring (push) with the world
of Eclipse(pull) in a way that leaverage the use of Spring since
pulling and pushing dependencies apply to be diffrent sets of
problems.
Is it granted that this feature would make it to the spring
framework? Since this wont break any
backward-compatibility requirements, it can be introduced
in the next Spring 1.x release easily.
Cheers,
Martin (Kersten)
|