Well, Actually I came from CORBA so EJB wasn't a big deal. I had "Hello World" up in 2 hours. I'm looking for a front end to an application that will be the core of a book I'm writing. The content of the book is all about the EJB side and I wanted a powerful but fast front end. Doesn't look like I'm gonna get my wish. And Honestly I don't have a month to blow.
-- Robert ----- Original Message ----- From: "Geoff Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 25, 2003 7:28 AM Subject: RE: The simplest possible cocoon application? > > ----- 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]> > --------------------------------------------------------------------- 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]>
