Antonio Gallardo wrote:
Sylvain Wallez escribió:
- 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?
Sorry, no time to study this particular point. I'm expressing general
feelings.
- 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?
That's precisely the point: do you really need Cocoon if you have no
pipelines? DWR perfectly does the trick in that case.
- 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. ;-)
You don't get my point. Dojo can be optimized and aggressively cached on
the browser. Once cached in the browser, the concrete things the server
has to do are reduced.
- 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.
Sure, but this doesn't mean its readable nor maintainable when you have
so many templates and need to use priorities.
- 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.
I don't blame any implementation, but think the concept is criticizable.
Using a form object model and flowscript to paginate a result table
seems overkill to me.
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.
Not at all. There's no code embedding. It's more like writing a Swing
GUI that would be associated to an HTML template that defines its layout.
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. ;-)
That's why there's no single silver bullet and one-size-fits-all framework!
Sylvain
--
Sylvain Wallez - http://bluxte.net
