> From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
>
> All,
>
> The "interfaces define everything" mentality is something that some
> consumers of Avalon (myself included) find troubling. Avalon
> Framework
> needs to (and in quite a few cases does) include conceptual
> documentation that goes beyond the interfaces.
Does the "Developing with Avalon" documentation fall short in this
respect?
> Interfaces do not define anything save interfaces. It's the contracts
> behind those interfaces that matter. Without the contracts, the
> interfaces are meaningless.
The interfaces are the points of contract that can be represented in
code. So it is *part* of the contract, but not the full contract.
Your point on contracts is well taken, and I have put forth much
effort to make the contracts explicit.
> Consider an Avalon Framework with all the lifecycle interfaces, but no
> lifecycle definition. It would be useless - containers would
> be able to
> implement lifecycle methods in any order they desired. You couldn't
> write a container-independent application using such an Avalon
> Framework. It is the lifecycle contract that is fundamental.
That is the way that Avalon *used* to be. The only contract was that
initialize() was the last method called. I took the time to work
with Fede to define the contracts we have now.
> In addition, by focusing on the contract it is most easy to see
> inadequacies in the framework. For example, the Context interface is
> sufficient for the needs of consumer apps. While it might be nice to
> have some syntactic sugar as in the Phoenix Block Context, it isn't
> strictly necessary. However the contract is clearly incomplete -
> without some sort of definition of container-common context
> objects and
> their keys no one can use the Context in a container independent way.
Agreed. We had some discussion on this a while back. We need
to formalize and write down the results of our conversations.
> For example, James, which is a pretty simple app from an Avalon
> perspective, would not be able to run in any random Avalon container
> that implemented the current Avalon Framework. That's because James
> needs the application home directory to resolve some of the file URLs.
> But since the key ("app.home") and the semantic meaning
> associated with
> the value returned (the application home as a File object) are not
> defined as part of the contract, a random container doesn't need to
> provide this. As I understand it Phoenix and Merlin both
> provide this,
> but it is not laid out explicitly in the Framework.
Right. Fortress also supports this if I recall correctly. That would
be one of the values.
> I'd argue that a standard, minimal set of keys/object should
> be part of
> the Context contract. Otherwise the Context interface is
> fairly useless
> as part of framework since every container would provide a
> purely custom
> set of keys/values. Thus any code written that implemented
> Contextualizable would be implicitly container dependent.
> There may be
> other ways to address this problem, and that's what I'd like to see
> discussed. This issue is obvious when one thinks about the contract,
> but is invisible when just considering the interface.
Right.
> This is only one Avalon Framework issue among a number that need to be
> discussed, clarified, and resolved. Clarification of these
> issues will
> make it easier, not harder, to develop new containers.
Right. Keep in mind the chicken and the egg issue. How do we know what
needs to be commonly implemented unless we have multiple containers
to work with.
> The only way to get a truly multi-container world is precisely to be
> crystal clear about what the Avalon Framework does and does not
> guarantee. I very much support multiple containers - and the
> ability of
> Avalon Framework consumers to write functional, container-independent
> applications.
Exactly. What I proposed in another thread is the creation of
a Container test suite that will work a container to determine if
it meets the minimum requirements for Avalon container compliance.
Again, remember the chicken and the egg issue. Now that we have
three robust containers, we can shore up the weaknesses in the
contracts.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
