Hi! I am no Cocoon developer, but I have been working with it, together with my team, since january, developing a real production application :). So having written quite a large number of components (or are they services?) and traced through the Cocoon code countless times, I think I might have something to add to this discussion as well.
Geez, this is going to turn out as a very long post - please bear with me. First I must say we're satisfied with Cocoon and with what it offers. But it DOES cause MAJOR headaches, which IMHO it didn't have to. Most problems probably stem from the fact that Cocoon was designed as a publishing, not an application framework. However, I chose to use it for our application, because of all web frameworks it best matched my former philisophy and best practices for building web applications. Before, I worked many years with Microsoft technologies and had no experience with J2EE. So maybe I could have chosen a more suitable framework for our task, but still I think the Cocoon philosophy is a good base for building even complex web applications with lots of functionality and not just publishing. However, in practice, it seems like as soon as you want to do things your own way and not the Cocoon way's, you start hitting walls which you need to cross with hacks and workarounds or by reinventing the wheel; walls being mostly a consequence of its lack of flexibility. Okay, not everything can be done with XML, that's understandable. But then, flowscript should have more power. There is only this very simple object model (the "cocoon" object etc.), which exposes very little of Cocoon's functionality. Okay, so you need to write components. That's no big deal, because they're fun and easy to write and the component system is one of the best things in Cocoon. But even then you realize that accessing the natural functionality (and power) of Cocoon is often very difficult, because there is no obvious API and no function library to access the core functionality. For example, when you need access to one particular piece of data or functionality (which you know is *somewhere*), you often have to browse or step through countless classes (don't forget, Cocoon has no small class library!) to find out where it is being kept. And even then, after several hours of search, the sought for object or method often turns out to be private and you can just go home and cry. Or modify and rebuild the framework, which is something I don't believe in. So, I really think Cocoon needs to be made more developer-friendly. First, it should be made more flexible by making its functionality more generic rather than "Cocoon-way-specific". For example, why does each flowscript call have to end with a sendPage? What if I don't want to "send a page" at that moment and just want to set up some data for later use in the pipeline? Also, by having to have a sendPage at the end of each flowscript execution, you have to write many pipelines for a single request, even if it's actually all just one logical pipeline, which makes the sitemap *EXTREMELY* unreadable. I think forcing a sendPage at the end of a pipeline is completely unnecessary. Why can't I just call a flowscript like an action? Now I prefer writing actions instead of flowscript, because they are more generic and don't impose any functionality I don't want. As another example, why does the authentication action always have to perform a redirect? I can perform the redirect myself if I want to, can't I? I want the authentication component to just "let me in" if I am authenticated, and if I am not, just continue and try to find another match - in other words, behave just like a matcher. For this, I did exactly that: create an authentication matcher (after hours wasted trying to get the action do what I wanted - and nothing else!). The next thing Cocoon needs is the already mentioned API. Cocoon has a lot of great and very useful functionality, but it's all burried somewhere in the huge pile of classes, which is very fustrating, because you can see it work, but you can't use it yourself, your way. What I'm talking about are functions for component management, pipeline set up and execution, cache management, sitemap introspection, programatic access to dictionaries etc. This is all very powerful and useful stuff, but now it's either use it the Cocoon way or reinvent it. I'd like to be able to look up and use sitemap components myself, programatically; set up and execute my own (dynamic) pipelines programatically; manage cache programatically, and so on... And also such an API would make Cocoon architecture itself much more clear. The flexibility achieved this way would make Cocoon a great platform for building web applications, and I think it would make it much more attractive. And the best thing is, nothing needs to be done but a little refactoring ;) Okay, this was a big joke, of course. I have no idea how possible or feasible all this is, I'm just telling it would be great. But in any way, during the development, you should always have other developers in mind. Keep in mind that different people want to do things diffrent ways, so you should keep everything as generic and as open for use and adaptation as possible. And don't impose or hard-code functionality that is not necessary for the given task. Now, another bothersome thing about Cocoon is its complexity. Stripping it to a minimum and documenting how to add what you need seems like a good idea (probably better than having to have 50 megs of jars in your lib). Perhaps an automatic dependency resolution... But it's not just about the complexity of Cocoon as awhole, there's also the complexity of its parts. Not everything is complex, of course, but some parts are way too complex. Combine this with inflexibility and you've got trouble. We just ditched CForms because of this and created our own forms framework, which is much simpler and more flexible (not to mention noticeably faster). It consists of about 5 (five) really simple classes (not borrowing anything from CForms) and one quite simple XSLT, and it already provides everything we need, including form definitions, validation and binding. It doesn't require writing three separate files (+ flowscript) for each form and allows mixing form content with HTML (and even executable XSLT!). Okay, this our solution may be too simple and too specific for our application to be used as a generic solution, but not necessarily. My main point, however, is not to brag, but to point out that simple and extensible solutions are more generally useful than complex ones with a ton of specific functionality and a specific way of usage. If something does provide a lot of specific functionality (which should only be a good thing), that functionality should be built on top of a simple and extensible core framework (and it should be documented what this core framework is and how to use and extend it!). Only thit way the specific functionality can mean an added value rather than a limitation! Cocoon's sitemap components model (generators, transformers, serializers etc.) is a great example of simplicity and extensibility. If only more of Cocoon was written that way... But currently most of its functionality is way too tied together. Oh yeah, and the sitemaps become too complex as soon as your solution requires more than just a few typical generate-transform-serialize pipelines. Splitting them into sitemaps doesn't help. What I'd like to have is the ability to split sitemaps into several *files* (not subsitemaps!) and bind them together with simple include operations. That way you could split your sitemaps into smaller parts however you wished, and also share common stuff between different sitemaps. There, now I think I've said it all. To sum it all up, I think Cocoon is far from obsolete, although it has become a bit of a dinosaur. I think its future depends largely on its developer-friendliness and adaptability (also keeping user docs up to date with the class library would be nice). Adding new components, no matter how useful, is going to do no good if developers can't find what they're looking for and use it the way they want. I'm keeping my fingers crossed... Best regards, Jaka Jaksic
