On Mon, 2003-11-03 at 22:33, Berin Loritsch wrote:
Sylvain Wallez wrote:
Sure I will. It would clearly be a bad thing to trash the time and effort Bering has put there. I may not have the required time to do it by myself, but I'm ready to answer questions. So maybe with the combined support of Berin and me we can turn this into a deeper knowledge of the sitemap engine for the whole group.
Berin, what's the major wall you hit in the TreeProcessor? AFAIU, Recomposable is a problem, but also something we can easily remove from the code with some light refactoring.
What are the other difficult points?
The TreeProcessor has a bunch of psuedo-components that are managed differently than the regular container. <snip/>
Just wondering: when does a component become a pseudo-component? As long as there is some code taking care of its lifecycle, I guess that would be enough?
Its the unclear management of the component. THe "psuedo-component" ascribes to certain parts of the component contract, but not all of them. Also in this case it is created by other components and then handed off to the tree processor to manage. A true component will support all the component contracts and be completely managed by the container.
That is the cheif difference. So with the TreeProcessor there is no complete picture of management--i.e. one entity to create a component and destroy the component as opposed to several entities to create components and one to destroy them.
If all of these things act like a Singleton, then the "bean" approach would work quite nicely. All we need to do is allow the beans to lookup and release the components as necessary.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin