On Sat, 24 Mar 2001, Peter Donald wrote:
> You mean discuss a strategy that components should conform to so as to
> interact with other frameworks? ... And if components don't implement this
> strategy (aka standard) do they go straight to jail without passing go and
> without collecting $200?
>
If we did things that way, you'd be right about likelihood of failure --
but that is not at all what we're wanting to do.
Configuration and lifecycle are issues for the application (or the
framework within which the application is being created), not for the
component. All the component needs to do is expose its configurable
options as JavaBeans properties.
Now, when an application developer considers using such a reusable
component, he or she can compare the integration cost (adapt the
component's configuration/lifecycle/logging/etc) to the redevelop cost
(write it myself) and make a rational "make or buy" decision.
Imposing configuration or lifecycle design patterns *inside* a component
simply increases the potential integration cost to the extent that the
design pattern inside the component does not match the design pattern of
the framework chosen for the app.
For example, Turbine and Velocity like to configure from properties files
(among other options). Struts, Tomcat, and many other apps like XML
config files instead. They can happily share components that make *no*
assumptions one way or the other about how config data is stored. Trying
to use a component that likes one style in an app that uses the other is
much more painful.
You're perfectly correct in saying that it is hard to build good reusable
components. I don't see that as a reason not to try.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
