Julian I'll jump in again. Not sure of the history of Struts, but Cocoon has been around (and evolving!) since at least 1999 - I think it more than qualifies to be a "long lived" product. As for "stability"; well, the Web is in a constant state of flux - I think any product that wants to maximise development opportunities *has* to evolve... which Cocoon has done, and done remarkably well. [this from a satisfied *user*, not developer].
As for adding in all the others aspects you mention; well, Lenya has a workflow management system in release 1.2: http://cocoon.apache.org/lenya/release.html and as you said yourself Cocoon tends to "sprawl" - so adding in even more options is not necessarily going to help make it easier to understand or use. But I believe that the blocks management system under development will go a long way to easing choice of subsets (or supersets) of current (and future) technologies to help build the suite of technologies appropriate to *your* webapp needs. The bottom line, for me anyway, is that Cocoon works because of a great community that has always supported it. If you choose to get involved and not just watch from the sidelines, you will find that out for yourself. Derek >>> [EMAIL PROTECTED] 2004/09/11 06:21:16 PM >>> Thanks Tony, I appreciate your opinions. The divisions I was referring to regard the blocks. My suggestion would be that the blocks are downloaded separately from the main Cocoon kernel with some basic samples. Also the blocks should have a separate section on the site for downloads, docs, etc. IMHO, this would clearly show to potential users that a Cocoon kernel exists and that several "apps" are built upon that kernel. I feel this is not clear, although I have understood it. BTW, hot swapping blocks sounds great! As far as the Forms are concerned, I do feel the current incarnation as being the most stable and developed attempt so far. I believe it would most likely stick around. Either way I am mostly concerned about developing in almost pure XML and in a newly developed tech. The stability and longevity of projects like Struts seem to be the way to go. Cocoon's kernel is great, but I am concerned with the maturity of the peripherals on top. I look forward to seeing how Cocoon's webapp framework evolves...mostly I'll be watching for the Forms, Flow, JSR-168, and (hopefully one day) workflow management system integration. Oh well, I need to continue comparing the pros and cons thoroughly before making my decision to stick with Cocoon. Thanks, -Julian --- Tony Collen <[EMAIL PROTECTED]> wrote: > Comments inline... > > <snip> > > Julian Wrote: > > > I think in > > > >>order to feel comfortable adopting these > >>implementations, I need to believe they won't be > >>scrapped and that there is unifying > model/philosophy > >>behind where/what Cocoon will become as it further > >>matures. Perhaps many of these projects should be > >>spun out of Cocoon into subprojects rather than > >>calling them blocks....akin to the Lenya app. > > I don't see CForms going away anytime soon, nor do I > see Flowscript. If > you're really concerned about where Cocoon is going, > please join the > -dev list and start a conversation about it. > > <snip> > > > **As it > > > >>stands the Cocoon project is becoming too big and > >>confusing as to what it really is.** This is a > burden > >>for neophytes. From the site's from page: > >> > >>"The Apache Cocoon Project is the open source > >>community project developing Apache Cocoon and > >>Cocoon-based application frameworks." > >> > >>I can accept this, but where is the division that > >>creates consumable parts? > > > > > > What division are you speaking of? The developers > recognize that Cocoon > > needs to allow dynamic loading of "blocks" and are > actively working on > > that. Or maybe that isn't what you meant. > > Yes, there are plans to allow Cocoon to have > hot-swappable pieces. This > is what's known as "Real Blocks," and it's been in > the works for quite > some time now. > > See > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109362470725423&w=2 > > for more information. > > Julian Wrote: > > >>Finally, running an app written mostly in xml > makes me > >>shake in my boots. I think Cocoon is great, but > >>sometimes too much emphasis seems to be put into > XML. > > Ralph's Reply: > > > Why? (BTW - Cocoon doesn't really run on XML. It > runs on SAX events). > > This "feature", in my mind, is one of its greatest > strengths as I find I > > can customize almost anything. > > Yep, and remember, the XML publishing is just one > aspect of it all. XML > is good for publishing... the view. Of course, you > shouldn't rely on XML > for stuff like Flow Control or backend stuff, which > is why we have > Flowscript and the OJB or Hibernate integration > writeups... > > >>I hope this helps rather than sounding like > endless > >>ramblings. If it is the latter, please accept my > >>apologies, but I fear that Cocoon is outgrowing > the > >>garden. > > Trust me, people have felt this way for years :) > > The best way to help is to contribute to the > project. Like I said, > subscribe to the -dev list and join the > conversation. > > Tony > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ===== Live simply so others may simply live. -Ghandi Pluralitas non est ponenda sine neccesitate. "Entities should not be multiplied unneccesarily" -William of Occam __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
