A fast checking to the matrix in: http://www.orbeon.com/community/cocoon
Pipeline language/Iterations -- In cocoon is posible with flow. Web Application/XForms support -- We don't nothing "propetary", we are an OS project. Perhaps "non-standard" is a better definition for Cforms. Languages/XSLT 2.0 -- Saxon. Languages/JSP -- "not encouraged", we have an special JSP block! Languages/Groovy -- built-in. Language/Javascript server side -- built-in. Document formats/PDF support -- In 2 trhough XSL-FO in 2 flavors: iText and FOP. Database support -- Built-in O/R mapping support for Apache OJB. You can also use Hibernate. Best Regards, Antonio Gallardo. On Dom, 17 de Abril de 2005, 16:56, Erik Bruchez dijo: > Sylvain Wallez wrote: > > > That is the exact definition of a marketing document rather than an > > objective comparison ;-) > > Then I agree, it is a marketing document ;-) This is just an > impossible task: when you are so into a platform or technology, how > can you be actually fair to others, in spite of your efforts? Then if > you were not that much into it, you would not see any benefit in > comparing it with others. Validation should rather come from > third-parties, but then how do you make such third-parties aware of > what makes your platform different? That's a catch-22 :-) > > > IMO you did a very good job at making XForms a strong marketing item > > for OPS (XForms comes first in OPS docs, before the pipeline > > language!). But your implementation is very far from being compliant > > to the W3C spec > > I reckon. Working on it though... > > > I admit XPL is elegant (and I told you so). There are a few points that > > hinder this elegance though: > > - it's hard to read, as it contains a lot of references to tie inputs > to > > outputs > > Debatable... But it's a little bit like variables in Java or XSLT, for > example. > > > - serializers mix concerns by defining both the XML to binary > > conversion (the actual serialization) and the destination of the > > serialized data. > > This has actually been fixed since then, with a split between > "converters" and "serializers". BTW this is not directly related to > XPL, rather to the way it is used, the bottom line being that XPL only > deals with XML infosets and doesn't know natively about "text" or > "binary". > > > So what is the <map:flow> about? Defining page flow controllers. It > > is declared in the sitemap because the sitemap is the entry point of > > every request coming into the system, and because sitemaps also > > define subcomponents in a large application. > > Sounds good. > > > Now OPS also has its mixing of concerns in the pipeline data where a > > single document mixes everything: xforms instance, description of > > the request, page data, etc. > > I don't think I agree with that. Those are usually available as > separately named pipeline inputs and outputs (therefore separate > documents / XML infosets), or requested with particular XML processors > (components). If you need the result of all of those in a page view, > then you may want to aggregate them. But the best practice is to > create a "nice" page model document which contains exactly the > information that needs to be presented in the page view. > > > Yes, Cocoon is inconsistent in some places. But this inconsistency > > comes from the incredible amount of features it provides and the > > fact that it was built by a large group of developpers. > > Granted. > > -Erik >
