Stefano Mazzocchi wrote: > > First of all, sorry for the major crosspost but I believe that it would > be extremely beneficial for everybody (heck, we are all parts of Apache > communities after all!) to discuss ways to integrate, avoid overlap and > reduce duplication of effort.
agree. > The only thing that needs to be addressed is web application support, > which is likely to overlap with existing solutions in the Apache world. Cocoon does have the beginnings of this support, but it is not documented well, or (possibly) not fully thought out. > In the last few weeks, I evaluated almost all existing web technologies > (ranging from Perl to PHP, ASP to JSP, Turbine to Struct) and I believe > that the design concepts Cocoon is based on are *almost* orthogonal to > the design concepts that web-app frameworks are based on. Ok. I can buy that. Since Web Applications are what I do, I agree to this point. I prefer the clean separation between form handling and form display. > Why so? Well, Cocoon is totally agnostic on how content is generated. > Cocoon provides an abstraction following the IoC pattern (IoC = > Inversion of Control), just like the Servlet API. Turbine does the same > with screens. Struct does the same with JSP as views. > > A question can be posed: where does Cocoon stand in the model1/model2 > concept? nowhere! It's just like a servlet engine: it's up to you to > write the generator! Another possibility is to use Turbine to aggregate separate serialized Cocoon streams.... > Cocoon provides a huge amount of machinery to > adapt/transform/change/serialize/mount/map/match in order to eliminate > the need for you, generator writer, about these things. Having worked on it in depth, I can tell you that the machinery is well-oiled with one exception: Cocoon 2 XSP generation is curiously slow. I am still looking into it to figure out why, but everything else is blazingly fast. > This said, it is obvious that frameworks that reside at "generation > stage" cannot call the container without breaking inversion of control. > It's much like the old getServlet() method that was deprecated from the > Servlet API. I agree. > Ok, you say, but why is this different from the Servlet API 2.3 > Filtering support? Why isn't Cocoon part of Tomcat directly? Well filters are great for invisible form handling (theorhetically). > Let's find out where the overlap is: > > 1) turbine is both a framework for web applications and a collection of > services. This doesn't overlap with Cocoon directly, rather with Avalon, > which is intended to be a framework for componentized serving > applications, thus is able to perform the same service functionalities > that Turbine does, with a few more capabilities (like component > versioning, dynamic componentization and the like). > > It would be extremely cool to factor out turbine services into avalon > components since: > > a) it would provide more 'meat' for the avalon component pool > b) remove duplication (Avalon contains a few services that overlap with > Turbine functionality, clearly a nonsense since they belong to the very > same community of developers!) > c) increase productivity and visibility of both projects by unifying > the noosphere. > d) increase functionality (ever thought of mail-applications? turbine > as a Mailet? you should since JAMES is built on Avalon and provides > almost all messaging needs including POP3/IMAP4 support!) I would keep them as part of Turbine, but simply letting them take advantage of Cocoon Components and Configurations will help give real feedback on how to make Avalon more usable, and provide the facilities to Cocoon--as long as the Roles are well defined. > Is there a reason to maintain Turbine separated from Avalon? I honestly > don't know, so I'm asking you. On the "well, we don't know what this > means" side, I'm sure there will be tons of people willing to help from > both the Avalon and Cocoon project for such a refactoring to take place. Yes. Avalon is a generic framework, 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. It depends on what the facility is. > 2) turbine as a framework doesn't overlap with Cocoon since Cocoon > doesn't care on how you end up generating your content. All the concepts > such as model2, model2+1, MVC, pushMVC, pullMVC, HMVC, etc.. all concern > the generation stage. > > The only overlap between Cocoon and Turbine is XSP, which is our > solution to custom generator creation. > > XSP 1.0 is a model 1 solution tuned for XML: I fully agree with Jon when > he states that XSP is nothing different from JSP in many situations > where lots of logic must be present. XSP is really nice, but there are some aspects I would like to see improve. Since this isn't the forum for that, I will leave the details out--I need to formulate what I *really* want vs. stream of consciousness rambling anyways. > In fact, evidence in the Cocoon user community clearly shows that XSP > are great for publishing (that is HTTP GET actions only!), but rather > painful for web applications (where POST and GET actions mix). The > reason? XSP 1.0 were not designed with MVC in mind, but to allow easy > generation of dynamic pages to be published. Here, Here! One thing I liked about ColdFusion (general mayhem ensues) was that it was easy to separate Pure content and Pure logic sheets with a simple relocation between them. However, due to some bad experiences with ColdFusion and the differences in the way some Web Servers handle (or mishandle) relocation, it was not a real solution for me. My introduction to Cocoon, and I was hooked. I had a template displaying how to reformulate the existing webapp into a Cocoon webapp shortly followed. It quickly became apparent to me that in the Cocoon 1 framework, there was no way to separate these concerns. This is frustrating because SoC (Separation of Concerns) is one of the founding patterns used in Cocoon and Avalon. With the Action framework introduced in Cocoon 2, I have the best of both worlds--although it could be made easier to use. > In the past, Cocoon design was criticized for some XSP design holes, I > would like to enphasize that this is equivalent of criticizing the > Servlet API design for some JSP design faults. Even more: unlike the > Servlet API/JSP, great care was taken in both making Cocoon completely > generation agnostic (the XSP component is itself a generator!) as well > as configuration semantics (unlike the Servlet API deployment > descriptors). > > XSP have been proven extremely valid for publishing needs, it doesn't > fit for web-apps, at least not in its current shape. > > What to do? > > Well, there are several alternatives: > > 1) add MVC strategies in XSP 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. > 2) turn Turbine into a generator and use directly Turbine stragegies Again, I have to research what Turbine strategies will afford me, and how they would be integrated > 3) factor out Turbine strategies and make Cocoon components out of this. This is relatively easy to do, though it has the most impact on Turbine. Again, I don't know a whole lot about Turbine. > 4) ??? Actions. Actions are unique to the Cocoon 2 framework in that they allow for two distinct advantages: They allow you to talk directly to the sitemap to control flow (based on administrator settings), and they allow you to perform invisible form handling without using clumsy relocation semantics. They are currently very specific to Cocoon, but seeing as they are Cocoon Components (and Avalon Components by extension), they provide most of the functionality that is missing in the Cocoon Webapp sphere. What would be possible is an Turbine StrategyWrapper in the form of an Action. It would allow Cocoon to seamlessly use already developed Turbine Strategies, as well as even the burden of development between the two projects. > I honestly don't know which out is the best for everybody: refactoring > Turbine into Cocoon components and Avalon components might tear the > project's identity apart and I don't this this is useful. There must be > a project focused on the development of web-app specific guidelines and > paradigms, neither Cocoon nor Avalon can do this as effectively. +10000. However, that project can't be ignorant of either Avalon or Cocoon--just as the others should not be ignorant of Turbine or even Struts. I must admit that I am guilty of this, and should look at how the projects can work together better. It is important to look at the same problem from different viewpoints. Avalon provides a framework and a view from the nuts and bolts side of things: more of a structural view. Cocoon provides a publishing framework and a view from URL contract management (sitemap) and publishing. Turbine as I understand it provides a view of WebApp organization and building. I haven't found ANY documentation on this other than API docs--at least that I can browse on the web. > On the other hand, once Cocoon2 and Avalon API stabilize, making Turbine > a Cocoon-based and Avalon-aware web-app sub-framework makes perfect > sense to me: it gives the 'turbo boost' for web-apps that neither Cocoon > nor Avalon alone can provide. The APIs are fairly close to stable... Cocoon 2 will most likely add some components, but other than that, the overall API has been pretty solid for a few weeks. > Ok, you might ask: this requires users to install yet another thing down > below and what for? > > Well, there are a few things you get for free: caching and content > aggregation, for example, advanced publishing capabilities become > available transparently and your web-app can almost instantly be turned > into a WAP-app by simply changing the stylesheets that transform the > content. If the end result is reduced time to market, then I am all for it. > Ah, I forgot: another critique that was moved against Cocoon was the > fact that XSLT is a difficult language and many don't like to be forced > to use it and like their own solutions better. XSLT is a pain in the butt. That aside, there are ways you can convert a regular HTML mockup into a "skin" for aggregated markup. > Well, just like we did for generation, even transformation is totally > language-agnostic: it is entirely possible to drive a transformation > process either directly (I mean: you write the java code that performs > the transformation) or interpreting a transformation language of some > sort (in that case, you have to write the interpreter). It is entirely > possible to use Anakia's velocity-based procedural transformation > language instead of declarative XSLT which some find less readable. There will be serious advantages for SAX based alternatives than something that requires a discrete transformation step. In other words, If you have to cache all the SAX events before transformation, then you are creating a performance issue--especially with large documents. > Again, even if Cocoon ships with an XSLT-based transformer, the overlapp > architecture was designed to avoid lock-in even for open standards and > allow you to personalize the component pipeline generation to the > granularity you want. I have found that using hand crafted Transformers will out perform XSP right now. This is unfortunate, but won't be long lived. > Another critique was the concept MVC is powerful enough to avoid the > need for transformation. That is: the controller can choose different > views depending on runtime parameters. In some ways absolutely. However, Cocoon will allow you to use ephemeral Models. By this I mean SQL ResultSets, [Enterprise] JavaBeans, and other proprietary models. When filtering is done at the Generation stage, we have a very good bet on not wasting resources. That is way XSP *uses* those models. If there is a way to use Turbine Models in the Generation stage, we could have yet another integration point. > This is a very powerful concept indeed: it is utterly inefficient to > generate a complex view of all the data contained in the model only to > 'filter them out' at transformation stage. Here, the MVC model is > clearly a winner. This is overkill in anyones book. That is why XSP and custom generators use existing models of Data, and only generate the portion needed at the time. > But, IMO, it is limiting to assume that since presentation can be > decided at generation stage, it is optimal to do so. Mixing presentation concerns and data models is IMO a bad thing. That is why I would create a model of say an Advertisement that can be represented in XML. I have the ability to transform my view (presentation/ transformation) into what I want and send it to the user (Serialization). > It is totally possible to concieve a system where both view choice and > transformation reduce overall maintenance costs. For example: views are > choosen as 'layouts' and trasformations as 'skins'. Why? because they > are two different graphical concerns: > > 1) where to place information / how to design the UI I do this in one Transformation layer in Cocoon > 2) how to present it I do this in another Transformation layer in Cocoon. > the use of different views allow you to have different layouts and > different presentations, but if you have m layouts and n styles, you end > up requiring n*m views while with transformations you would only need m > views and n styles. Already possible with Cocoon, but definitely could be optimized a bit. > It also takes into consideration the fact that normally UI designers and > graphic designers are different people with different skills: MVC forces > them to work together only because both happen to impact on the > 'presentation' of the information, even if with different aspects. I definitely agree here. I worked on a Workflow system where the layout was designed by Developers (with no sense of style or placement). My first task was to retrofit the existing app with the Graphic designer's idea of how the WebApp should look. After I was done, the app had style, but wasn't very usable. I took my team of two, and we went through the feedback from our customer. We identified some common structures of how to layout an Inbox oriented Workflow that really worked for our customer. Again with the retrofitting. This retrofitting required altering over 200 templates, and it was HTML mixed with the logical markup. Now you can see why I am heavily biased toward Cocoon. It fills a serious need we have in the way we work at my company. The graphic artist is usually contracted too late, and then the rework ensues. With Cocoon as my publishing engine, I can change the look of my entire webapp in one file--this is invaluable. I can also change the overall layout with a second file. I typically stick with traditional data models, using Cocoon as my View layer--and now with Actions, my Controller as well. Now, I am very willing to entertain how Turbine in the mix could assist me as well. > 1) Cocoon and Turbine don't overlap but the assumption that Cocoon can > be called by Turbine as a screen is misleading and ruining the design > concepts that Cocoon was based on. This is, to me, the reason why nobody > was able to integrate Turbine and Cocoon elegantly up to date (see > Jetspeed). Integration is a difficult issue on many levels, but I would need better understanding of the specific problem domain in order to come up with good solutions. > 2) I explained why an XML web applications can use both Cocoon and > Turbine functionality only if Turbine is contained by Cocoon and not the > other way around. I think this is the proper approach. Imagine if you will a Turbine Generator and a Jetspeed Aggregator all stylized by Cocoon. I think that would be Really cool--because now I am working on a "portal" of sorts. Right now, it is more painful to do what I need, but I can't take the risk that the site won't be restyled later. > 4) I explained how many of the critiques that were moved against Cocoon > were in fact against technologies that Cocoon was using to implement > some of its components. No critique, so far, has mined Cocoon's core > design concepts. 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. > 5) I explained how the use of both Cocoon and Turbine functionalities > can be useful to reduce costs for web-app generation and provide great > synergy between the two communities that can exchange information and > design guidelines to improve both sides of the fence. I like the prospect of this. Is there any other methods besides Turbine Generators and Actions?
