cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Release early? (was: Roadmap Executive Plan)
Date Mon, 11 Mar 2002 17:59:46 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>>a) Sitemap components in the cocoon.xconf.
>>>Now, personally I don't like this - but that's my own opinion about this.
>>>If you want to edit the sitemap, you not only have to look at the sitemap
>>>but also at the cocoon.xconf. This makes handling the sitemap even more
>>>I know a lot of people complaining about the complexity of Cocoon and
>>>the many places of configuration. By this splitting of component
>>>definition it gets even harder for beginners.
>>>So I would like to have all these definitions back in the sitemap.
>>>What is the benefit of having them in the cocoon.xconf?
>>The benefit is reduced length of the <map:components> section in the
>>sitemap, which is both tedious to copy/paste in every sitemap and really
>>frightening for some beginners, and provide some sitemap components to
>>other components that could use them (thinking mainly about the xml
>What do you mean by copy/paste in every sitemap? I assume you don't mean
>sub-sitemaps as they inherit the components from the main sitemap, right?
No, of course no :) I was talking about the root sitemap of each 

>Hm, other components can use the sitemap components if they are instantiated
>from within a sitemap component.
Yes, but some are created outside of this scope. These are for example 
SourceFactories, which may need a serializer.

>>About frightened users, what about reversing the order of sections in
>>the sitemap : start with pipelines, which describe the contract with the
>>external world, then resources, view, actions and lastly components ?
>Sounds not so bad.

>>>b) the sunRise and sunSpot components
>>>What is the feeling of the community to move them out of the scratchpad
>>>into the main trunk? I'm - of course :) - +1 on moving them.
>>Before moving sun* to the main trunk, we should discuss how it could be
>>better integrated into Cocoon. For now, it's in Cocoon's CVS (thanks
>>again for this donation), but is built 'on top' of it, while some of its
>>components are of general purpose and could be moved in existing Cocoon
>>packages where they could gain more exposure and thus a wider use.
>Yes, good idea!
>>A question about sunRise : is it possible to use standard HTTP
>>authentication and authorization ? AFAICS, it seems to be very tied to
>>form-based and application-managed authentication.
>You can use any information you can reach from within the Java code.
>I'm not sure if there is a change to get the HTTP authentication infos.
>If yes, you can use sunRise.
The problem comes from the login page. With HTTP authentication, you 
don't have a dedicated login page, and thus cannot use this one to 
handle authentication. Or did I miss something ?


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message