Carsten Ziegeler wrote: >Sylvain Wallez wrote: > >>Carsten Ziegeler wrote: >><snip> >> >>>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 >>>complicated. >>>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 >>serializer). >> > >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 application.
>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. > Cool. >>>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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]