cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [CForms] Streaming out widget attributes?
Date Thu, 03 Aug 2006 06:04:41 GMT
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.


Mime
View raw message