Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 66228 invoked from network); 26 Feb 2001 21:53:22 -0000 Received: from laswell.sp.collab.net (qmailr@64.211.228.55) by h31.sny.collab.net with SMTP; 26 Feb 2001 21:53:22 -0000 Received: (qmail 27222 invoked from network); 26 Feb 2001 21:52:38 -0000 Received: from jonmac.whichever.com (HELO ?157.22.245.2?) (157.22.245.2) by laswell.sp.collab.net with SMTP; 26 Feb 2001 21:52:38 -0000 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 26 Feb 2001 13:53:24 -0800 Subject: Re: [RT] Cocoon and web applications From: Jon Stevens To: Avalon Development , CC: Ricardo Rocha , Berin Loritsch Message-ID: In-Reply-To: <3A9ABDD6.BB71E902@apache.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Ok, I apologize in advance if this sounds harsh in any way. It isn't meant to sound harsh. So, take everything I say with a grain of salt. thanks, -jon on 2/26/01 12:34 PM, "Berin Loritsch" wrote: > Turbine is a specific framework. There > is nothing that says that Turbine can't be built on Avalon, nor is there > anything that says that pieces of Turbine could be included in Avalon. Yes there is. The fact that it would end up breaking a lot of people's code and the fact that the configuration is entirely different between Turbine and Avalon. Those are two MAJOR issues that no one here likes to even think about. People just like to say that it can be done...but in reality, it can't unless you want to also upset a lot of people. Add to the fact that up until just recently (thanks to Sam's efforts), Avalon has been a terrible moving target. Given that Turbine is enough of a moving target itself (yes, it is often as bad as Avalon or worse), compounding that with a dependency on another moving target would be suicide. Note: Turbine has no official release. Therefore, the fact that it is a moving target is ok due to the fact that it should only be used with non-released-code disclaimers. Solve those problems and I would be more than happy to have Turbine use Avalon where it makes sense (I have been saying that for years now). However, the fact of the matter is that I don't see it happening unless someone steps up to make it happen. Of course I wouldn't -1 it, but I sure am not going to do it. What I have works just fine now and Avalon isn't my itch. I don't need blocks, I don't need stuff componentized into a bazillion pieces. I just need a web app framework. > This has promise, although I would have to give some time to research > the Turbine MVC patterns. There is alot that could be learned here. Nice to hear you say that given that the Action framework you just talked about in Cocoon 2 is essentially something that was invented at least 4 years ago (even before Turbine existed) by my friend Leon Atkinson and was done first in PHP! I find it humorous that this same Action framework is also in Struts as well. More re-invention of the wheel because no one bothers to look at Turbine first or people claim that Turbine isn't J2EE so they don't want to use it. Duh. How lame. > XSLT is a pain in the butt. I can't agree more. It is more than just a pain in the butt, it SUCKS for webapps. So far, the only cool XSLT application I have seen is Gump, however, making modifications to the XSLT source code in Gump would give me a headache. > Where have you heard these critiques. Everything I have read has been > pretty much pro-Cocoon. I mean Cocoon really excites the imagination > of what can be done. When you marry it with other less glamerous projects > the result is a net boon for all projects involved. It brings more > users to the table for all of the technologies involved. "Less glamorous [sic] projects"????????? Excuse me, I hope that you are not referring to Turbine with that statement. Combining all of our efforts together really is not a boon IMHO. The Turbine project has been chugging along for over three years now and we have not seen nearly the amount of political crap that other projects have been seeing. No offense, but I don't want to bring that political crap into Turbine at all and if someone did, I would personally flame them right off the list. I would rather see us in Turbine land develop things more slowly than have people messing up the Turbine project with political crap. I have been asking for years now that the Cocoon people take a look at Turbine, yet no one has bothered to do so. When people went gung-ho into XSLT and Cocoon, I sat back and watched and waited. Now people figured out that XSLT sucks even though I said XSLT sucked early on. What a joke. Spend some time with Turbine and see how we do things before making ANY further comments. Download the TDK and play with it. Try building a little application. Please don't let me hear you saying that Turbine could be this or that (even though you haven't even looked at it!)...it already is what it is and that is good enough for quite a lot of people. Not everything has to be J2EE or W3C or Jakarta-Combined-Library in order for it to be cool and do the job extremely well (and often much better than the "standards" based way of doing things). Speaking of doing the job: Turbine does ONE THING VERY NICELY. It allows you to build web applications without having to constantly re-invent the wheel with commonly developed code. Velocity does ONE THING VERY NICELY. It provides a nice template based View/Controller part of the Model. Do you see a pattern there? No, I'm not talking about a OO pattern (which is what Avalon and Cocoon tend to stick with)...I'm talking about an overall design pattern. Seeing projects like Cocoon trying to do a bazillion different things and only being able to do an ok (not excellent, but not horribly bad) job of each of those things (for example, Cocoon is great at output into a bunch of different formats, but sucks for webapps). You can't build one tool that solves every problem. For example, that is why there is "cp" and "mv" on Unix...they each do one thing really well. My vote is that if you really want to see Cocoon working with Turbine...or you want to see Cocoon become a web application framework, then you should figure out how to build that on top of Turbine instead of the other way around. Turbine is not nearly as complex as Cocoon and it shouldn't be that difficult given that Turbine already integrates a bazillion other tools. p.s. There is no turbine-dev list or a java-apache-framework list and cross posting across a bazillion lists is inconsiderate given that people won't see the rest of the discussion. thanks, -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous &&