> ----- Original Message ----- > From: "Jeff Turner" <[EMAIL PROTECTED]> > To: "Cocoon Users" <[EMAIL PROTECTED]> > Sent: Saturday, January 25, 2003 6:02 AM > Subject: Re: The simplest possible cocoon application? > > > On Sat, Jan 25, 2003 at 05:21:13AM +0100, Robert Simmons wrote: > > > I currently have the cocoon war installed on my JBoss 3.0.4 server. It > > > works fine. I deployed a second war file that contains an XML and an > > > XSL. The XML has an embedded xsl:stylesheet processing instruction. > > > > Embedded stylesheets are very unusual.. are you sure it's > Cocoon applying > > the embedded stylesheet, or the web browser? > > Hmm, how could I tell? What would you use if you didnt embedd the > stylesheet into the XML? Oh, I get it, the pipeline tells it what > transform to make ? > > Addendum: I undeployed cocoon from jboss and the transform still > worked. Must be the browser doing it. OOK .. =) Now I feel like i > actually know LESS than before.
Bingo. My understanding is that Cocoon1 used/allowed embedded stylesheets but cocoon2 ignores them because they tie you to one view. > > > Ok so here is the question. I am now thinking of doing something a bit > > > more than static XML pages. What would be the bare minimum? Do I have > > > to copy the cocoon war and all the libs in it to another deployment or > > > can I use the jars already deployed in the war? Much of what ships with cocoon is optional - at this stage there is a "kitchen sink" philosophy for distribution: everything is turned on by default, every optional part is included by default. Good for showcasing but obviously not needed for deployment. The binary distributions will come like this, so you may want to consider building from source and specifying build properties so that only what you need is built. If you have a source distribution or cvs checkout, look in the lib directory and you'll see (at least) two directories. Obviously everything in "optional" can be removed if it looks like something you don't need (probably a lot). The old build system (2.0.3 and maybe 2.0.4) relied on the presence of those jars to determine what you wanted included. If you're using 2.1 dev, have a look at properties.xml in the main directory. This is where build properties are specified. Not sure if you're familiar with ant, but the way its properties work you can override those settings without modifying the file by including a .ant.properties file in that directory (or in your home directory) and those will take precedence. Those files have a different format by the way. Unfortunately, you can't undefine a property and the build in some places relies on the presence of a property to determine behavior (at least it used to) so there you'll be stuck modifying the original file. There is a new concept aimed at separating core elements from optional ones called "blocks". This provides even more ability to trim out unneeded elements, but I think it's only in 2.1 (although it may be in 2.0.4?). properties.xml specifies which blocks to build. > > > > Each war has one main sitemap. Each sitemap can have lots of different > > pipelines. Where did the 'second war file' you mention come from? Did > > you copy the sitemap and WEB-INF/cocoon.xconf from the Cocoon samples > > war? > > > > What I mean is that, if possible, I dont want to copy the whole > MASSIVE jar library in the cocoon distribution war into every > blasted web app that I create. Trimming the size of the webapp as described above will help, but also consider whether you need each to be a separate webapp, or can deploy them within one cocoon instance. The cocoon concept of "mounted" sub-sitemaps get you a lot of what you'd want with separate webapps. Maybe if you voice a few specific issues others can help figure out whether this solution will work for you. > The thing thats stumping the > newbie here is how a user uses it. It almost seems like i have to be > practically a dveloper on cocoon to use it. I honestly dont care > how it works, I just ultimately want to write come generators that > smack a EJB and spit out XML that then gets transformed. Well, that's pretty easy. I'd suggest first starting with static xml files using the wiki page Jeff provided to get the basics of using the sitemap and pipelines, then try building a few simple generators following the tutorial (http://xml.apache.org/cocoon/tutorial/tutorial-generator.html). Then you should be able to use your EJBs in generators. > Basically what i have right now is a normal java servlet that builds a dom > document, serializes it to xml and trusts the xsl transform to > put out the html and so on. One option would be to reuse much of the existing code and use the dom in your generator. Cocoon2 is built around SAX though and you may get better performance (and use less memory) by going that route. If by serializing to xml you mean it outputs a string, or character stream, you definitely want to get that step out of the new code - you lose the benefit of the pipeline architecture. > The servlet has a massive number of > methods from all the commands being handeled. I'm assuming by command you're referring to a MVC type scenario. Cocoon is so flexible on how to accomplish that as to be confusing. You'll need some combination of Matchers, Actions, and Selectors to determine flow. There is a new method called "flow" but it is probably not yet mature enough for your taste. > I want to nuke that > servlet and instead write cocoon generators to spit out the xml > and then let cocoon do its magic. However after 12 hours of > reading, Im still a tad lost. Ask some specific questions. > > > Note. The lack of truly newbie cocoon documentation is appalling. > > > > Fortunately we have a Wiki where anyone can document things. This page > > looks quite relevant to your question: > > > > I will read it ... but I have to say that this looks liek a very > powerful front end that once you know it, it is great. Prior to > that there is ALLOT of head scratching. And I dont think im any > lightweight at programmign either. Well, I'd suggest buying one of the three books available on cocoon. I've looked at all three but don't own any so can't give you suggestions except that they all look good (with the warning that because of publishing cycles they're all probably out of date in some areas but the authors are active on the cocoon lists) The concepts are new and in many places sophisticated but not impossible to grasp - and since most of your logic is already encapsulated elsewhere you're not going to need a mile deep knowlege. You certainly didn't learn EJB's in 12 hours? > > http://wiki.cocoondev.org/Wiki.jsp?page=SimpleTransformations Yes, that's probably a good place to start. Geoff Howard --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>