cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [CForms] Streaming out widget attributes?
Date Thu, 03 Aug 2006 08:00:38 GMT
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 

>> - 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: 
> 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 Wallez -

View raw message