cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: [CocoonInAction] 2 new articles
Date Sun, 17 Apr 2005 23:03:45 GMT
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
>


Mime
View raw message