On Fri, 2009-12-18 at 23:43 -0800, Ralph Goers wrote: > Actually, I could agree with that, although there are other choices - such as > having GWT use JSON objects. As I reread your comment it occurs to me that > you are actually agreeing. Using Cocoon to generate and process XML is what > it excels at. Feeding that XML to a UI component is certainly a great way to > use Cocoon. But there are better choices now other than having Cocoon manage > the whole web page or site and dynamically generate the page content. >
I am using lately wicket for gui development, that combined with cocoon for presentation and transformation via cocoon3 (thanks to Reinhard for the wicket block) is a pretty solid and efficient solution. However JSF has its use cases IMO when a very high degree of control of the ui is needed but it comes with the price of maintaining lots of mapping files. I agree with Ralph that GWT is much nicer for that. salu2 > Ralph > > On Dec 17, 2009, at 7:36 AM, Andreas Kuehne wrote: > > > Hi Ralph, > > > > I would like to give a slightly different view : > > > > As a server for XML requests coming from the Ajax UI implementation ( and > > probably serving the web pages ) Cocoon _is_ the recommended way to serve a > > state-of-the-art UI ! > > > > Greetings > > > > Andreas > > > > > > > > ----- Original Message ---- > > From: Ralph Goers <[email protected]> > > To: [email protected] > > Sent: Thu, December 17, 2009 4:24:24 PM > > Subject: Re: Use Case for Cocoon with JSF? > > > > Before you undertake this it would be wise to understand your use case > > better. Earlier this year we did some benchmarking by creating some > > portlets using JSF and IceFaces and determined that they would not even > > come close to scaling to our requirements. The same use cases reimplemented > > using Spring MVC and JQuery or GWT had no problem scaling. If your use > > cases are heavy-weight applications with multi-page flows then JSF would > > still make sense, especially if your load isn't all that high. > > > > As for using Cocoon for the UI, given the state of UI technologies I don't > > think I'd recommend Cocoon for that any more. However, for manipulating > > XML-based content it is still a great way to go. For example, converting > > content in a CMS from XML to HTML, PDFs, etc. > > > > Ralph > > > > On Dec 17, 2009, at 6:34 AM, Wendy Bossons wrote: > > > >> I take it no one can come up with a use case for Cocoon with JSF. . . so I > >> will consider my rewrite as a new JSF application, without Cocoon. That > >> seems to make the most sense. > >> > >> > >> > >> ..\Wendy > >> > >> > >> Wendy Bossons > >> Web Developer > >> > >> Contact Information: > >> [email protected] > >> 617-253-0770 > >> > >> > >> > >> > >> > >> > >> On Dec 14, 2009, at 11:11 AM, Wendy Bossons wrote: > >> > >>> Hello, > >>> > >>> I am new to Cocoon . . . however, the project on which I'm now working is > >>> Cocoon based and has a significant code base . . . I would like to create > >>> a JSF frontend to this application, have been given the go ahead to do so. > >>> > >>> As I begin, however, I'm finding only older resources on the web > >>> regarding integrating JSF and Cocoon (circa 2004) . . . and in the end, > >>> these end up back in the Cocoon pipeline as XML/XSL transformations. So > >>> I'm wondering what's the use case for integrating the two? My initial > >>> hope was to simplify the user interface and to take advantage of the many > >>> features of some extended JSF framework like IceFaces. > >>> > >>> Can someone speak to this idea ... what is the use case(s) for moving to > >>> JSF if it all ends up in an XSL transformation in Cocoon? > >>> Wendy Bossons > >>> Web Developer > >>> > >>> Contact Information: > >>> [email protected] > >>> 617-253-0770 > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Thorsten Scherler <thorsten.at.apache.org> Open Source Java <consulting, training and solutions> Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U. (SADESI) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
