Leo Sutic wrote: >>now what? > > I thought I'd leave that up to you... > > OK, now that we know what to build, let's start thinking about how > to get there.
The concepts are getting too big to fit into memory (or an e-mail) fast. We need some working code :D. I won't have much more time until, oh, next tuesday or so.
> The problem is that we suddenly need one more bit of metadata: Is the > interface stateful or stateless?
ugh. What about stateless interfaces implemented by stateful components? Or..., or ...
(still thinking)
== terminology ==
I dislike "Factory" and "TransientFactory". They make it sound like the client has anything to do with creation. How about "Handle"?
I also dislike "Plugin" as it is too generic. But haven't figured out anything that's really better yet (I use "Adapter" and "KeyAwareAdapter" in jicarilla atm, but that's not quite brilliant either).
== plugins ==
So suppose we move to a Plugin based container as we outlined:
public interface Plugin {
/**
* @returns Factory if interface is stateful, component * interface if stateless
that sounds like too complex a contract for a core method....
public interface FactoryPlugin
{
Object getFactory();
}
public interface ComponentPlugin
{
Object getComponent();
}
public interface AdaptivePlugin
{
Object get();
}hmm. Ugly.
So we need to define the client type to handle backwards compatibility:
not just backwards, also sideways. This is a quite general requirement, I think, for portable IoC.
So we need two types of plugins:
1. A component handler plugin. (For example, a plugin that manages A4 components.)
2. A client-side adapter plugin. (For example, an adapter that converts the plugin-style lookups (with Factories) to A4 lookups, as outlined above.)
would seem like it. But then again, a provider component that follows A4 contracts is also quite often a consumer component that follows A4 contracts. All IoC frameworks today couple the two; I'm not sure we need to decouple. Your sample does seem to indicate we do. I need to write some code :D
== Plugin is-a component? ==
Leo Sutic wrote: > Just realized that we need a way for Plugins to find each other:
I don't think so. The same mechanisms used for components can prolly be used for plugins. IE:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/jicarilla/jicarilla-sandbox/platform/container/impl/src/java/org/jicarilla/container/builder/DefaultBuilder.java
a plugin is-a component. That's too powerful to not do it :D.
You put plugins in a container and use them to build another container. There's bootstrap issues, of course, meaning the plugins need to have a simple container-component contract. You could add another level of plugins, but I doubt we need it.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
