Sylvain Wallez escribió:
[resent -- seems to have been lost]
Reinhard Poetz wrote:
Sylvain Wallez wrote:
I'm sorry to say that over time, I found Cocoon to be more an
obstactle for complex webapps pages (not talking about flow) than a
real help, and that's why I'm moving away from it. So I don't care
as much as I did...
Can you give conrete examples on what these obstacles are?
Well, here are some:
- in complex use cases the GUI logic, as Carsten's use case
exemplifies, becomes spread all over the pipeline, and it becomes
increasingly difficult to understand what happens where.
Could you explain how can you do the Carsten need easily with Wicket?
- client/server communication with JSON makes it really easy to build
Ajax apps, but is a pain to produce from Cocoon unless we directly
send it from the controller, which actually makes Cocoon pipelines
useless.
Why everything needs to go through pipelines?
- Dojo widgets are a nice replacement for CForm's styling stylesheets,
reduce the server load, and again make pipelines less useful.
Here is a trade off dojo reduce the server load but increase the client
load and bandwidth:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=dojo+fat&q=b
I am not telling dojo is bad, I like it, but I see here is a trade off.
Dojo usage is not a free lunch after all. ;-)
- enhancing the CForms styling leads to a giant XSL (even if
modularized) where every possible styling used in the application must
be present.
It's not my experience. xslt allows us to just overwrite the required
pieces to enhance the styling.
- since only CForms has Ajax integration, people are over-using it for
presentation purposes (e.g. paginated repeater)
I agree with you, mixing binding with form definition is not good. We
want to keep it separated. However, I think it is a first implementation
wich show us a way to implement a paginated repeater after all it is not
released yet. It is a work in progress. Is not fair to blame to a first
draft implementation.
Don't get me wrong: Cocoon is a killer for publication. But for
webapps, other approaches, more Java-centric, are worth considering.
My current choice is Wicket, which was just proposed for incubation.
I took a fast look at wicket and I can see an analogy to building a form
intensive application with XSP logicsheets. I already went this way and
I can say it is not not easy to maintain the code. I mean it is the same
code embedding concept with a new syntax sugar after all.
Cocoon allows lots of non-Java people to build complicated stuff, and
this is a major achievement. But I find it easier to write Java if
you're fluent with it rather than finding workarounds in an
XML-centric framework.
I feel myself fluent in Java and I still prefer find faster to write a
cform application using with cocoon. ;-)
Best Regards,
Antonio Gallardo.
