Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)

[Bruno Dumon <br...@outerthought.org>]

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?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)

[Berin Loritsch <bl...@apache.org>]

Bruno Dumon wrote:

> 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