Stephen,

Which one is fine?

a) A-F interfaces only
b) A-F interfaces + meta

And for me option (a) is insufficient and the root of current container proliferation. Option (b) is crucial for completion of the component-container contract.

Signing off now from internet cafe in Amsterdam. Hmmm, it might have been good to meet up with
Leo Simmons. I'll reply more fully in a day or so.

The answer is interfaces only.

That's what I was worried about.
That's what I was worried about :-)


I like the way that Leo Sutic's thread is progressing.

Leo's approach does not negate the requirement for knowlege about context interface casting criteria or entry key/class criteriea. I potentially adds the notion of a context criteria being declared with multilple interface classes that it must support (which is managable), and lets us as a result, establish a set of standard context accessor interfaces and implemetaitons. Apart from that the container/component contract issue is still there and isn't going to go away.
No, actually, I think Leo's solution is just fne. Containers choose which (core) Context derivatives they support.

Question : Is it possible for us to deal with the long-running Context sub-interface issue
separately from XML meta info on components. My opinion is yes, and given it is something that we
can resolve quite quickly, we should do so.
And my opinion is no.

If you seperate these two, you effictively say

"let's abandon the idea that a compont author can define *portable* context solutions"
With respect, I said nothing of the sort.

Can you explain to me why this is a good thing?
If I understood what that (non-quote) means, I might do.

Look, we can either squeeze some context interface only solutions into Phoenix codebase without revolutionising anything, or if they really are tied to the uber-meta, then they only go into ubercontainer and Phoenix sails on with BlockContext as is. We've committed to no revolution on Phoenix CVS. Uber can take whatever fantastic collaborative Context design it likes.

- Paul


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to