Hi! > Hi all, > > I am currently learning Cocoon2 for use on an intranet server. We would like > to deploy a role-based portal for our users to give access to various > datasources and as a front-end to a set of other webapps. In the learning > process I have a couple observations. These may be in the process of > resolution and planned, I don't really know.
There are a lot of things planned and in process. See cocoon-dev mail list archives. > > 1. The tight integration between the cocoon framework, samples and > documentation makes it difficult to understand the basic requirements for > applications. I think chello tried to do that but it is now out of date. A > 60k sitemap.xmap is quite overwelming! I believe cocoon blocks will help > this drastically but can't the samples, documentation, and portal be moved > to sub-sitemaps and somewhat separated from the framework directory > hierarchy now? This work on samples is in progress. Just look at the /src/webapp/samples/ directory. Work on the documentation is also in progress: both on the content and structure (both at Apache Forrest and Cocoon Dev). > > It would be fine to leave a large sampling of core generators and > transformers, etc. in the main sitemap along with a basic "home page" to > point to the sub-sitemaps. This page could easily be replaced for an actual > deployment. Yes, we are moving in that direction, though a little slow. > > 2. In reading the documentation on session contexts (from CVS) and under the > section on Context-Tags it lists names which cannot be used (request, > response, session, context, temp, portal or authentication) because they are > built-in. These seem fine except portal which is an application and > shouldn't be a core context. Agree. Could you point me to that document? > > At this point I am working on understanding the framework and I think it > will be great for my application. The examples are pretty nice as well but > figuring out how to strip things down to just what is necessary and not > having to build the samples and other optional parts on an ongoing basis > would be very helpful. A "best practices" for laying out an application > would be great as well. It seems every example I have found uses a very > different directory layout and agreeing on a base structure would make > comparing and reviewing various uses much easier. In progress. > > > Please be patient with me as I get started and please point me on my way! You're welcome. -- Konstantin > > > (now if I can just get the cocoon portal working...) > > dave > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
