Agreed. I am not what the exact "productivity scalability issues" are: 10 forms are 10 forms - not sure how you can get around this in Cocoon (or how you get around this in any other framework?)... but I guess if there is enough similarity, you could always store their attributes in a database and create them dynamically. Also not sure why you need a "plethora of pipeline definitions" - pipelines are designed to work on pattern matching and you should not need more than a few to handle this situation (most are obvious and straightforward). And there are only really two technologies here: XML/XSLT and Javascript. But if you
don't know either of these, then I agree that Cocoon can be difficult to assimilate... >>> Dev at weitling <[EMAIL PROTECTED]> 2007/06/04 04:15 PM >>> Hi Christian, I don't know JSF/MyFaces yet, but consider my 2 cents: You may put those ten forms into one, making "page" switches e.g. via Ajax/union widget. Though I would not recommend it :-) I'm at the moment forced to code forms via plain JSP. And it's ugly mixing view, logic, model. So it really makes sense to split it into several parts. Bye, Florian Christian Schlichtherle wrote: > Hi, > > as I said I am new to Cocoon. My point was just that within Cocoon you could > do Forms "the Cocoon way" with Cocoon Forms and either Actions or Flow or > you could do them "the JSF way" with the MyFaces implementation. > > As you figured, with both approaches, I could build forms which produce XML > and then use a Cocoon pipeline to render the output to (X)HTML. > > Now my question is which route to follow. Here's my impression so far: > > + AFAIK, Cocoon Forms produce SAX events and hence should perform very good > when combined with the rendering pipeline. I don't know how I could make JSF > generate SAX events rather than a text stream with XML. > > + On the other hand, I foresee productivity scalability issues: Suppose I > need to do ten forms. With Cocoon Forms, I would have to do ten Form > Definitions, plus ten JXTemplates, plus the controller logic plus a plethora > of pipeline definitions in sitemap.xmap. This doesn't scale very good and > uses a mix of very distinct technologies. > > All in all, I appreciate the potential performance benefits with Cocoon > Forms, but I'm not impressed by the effort to get to it. > > So I would like to know best practices from other users. > > Kind regards, > Christian > > >> -----Original Message----- >> From: Ralph Goers [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 04, 2007 3:27 PM >> To: [email protected] >> Subject: Re: Cocoon Forms vs. JSF >> >> Forgive me if I am misunderstanding, but I'm having a hard >> time understanding your question. JSF is essentially the >> controller in MVC - your faces config identifies the view >> states to go to based upon the view state you are currently >> in and the outcome of some actions. JSF provides no specific >> view handler, but defaults to use JSPs with special tag >> libraries. Interestingly, almost no one recommends using >> that. I work with several applications that use JSF with >> facelets and it works OK. We use JSF to build JSR-168 portlets. >> >> Cocoon, on the other hand, in my opinion is best used as the >> view handler. I have a very large Cocoon application that >> uses the Cocoon portal to manage the site layout and >> aggregate various pieces together, many of which are XML >> content. Cocoon is fairly efficient in doing this, largely >> because it makes extensive use of caching. For the controller >> you can certainly use flow, and many folks here do, but if I >> was writing an application that needed more than a primitive >> controller (which the Cocoon sitemap provides) I would prefer >> to use something like Spring WebFlow instead. >> >> I have to wonder why you would say that you don't need >> continuations if you are considering JSF? JSF is very heavy >> and its benefits really only come into play if you have an >> application that has multiple paths through several screens. >> It uses something similar to continuations to keep track of >> what the current view state is. >> >> I'm afraid I don't quite grasp teh question about reparsing. >> Are you suggesting using JSF with Cocoon as the view handler? >> (The JSF block demonstrates that that can be done). >> >> Ralph >> >> Christian Schlichtherle wrote: >> >>> Hi, >>> >>> I'm pretty new to Apache Cocoon, so this may be stupid question: >>> >>> I've looked at Cocoon Forms and JSF. Regarding form >>> >> processing, both >> >>> seem to be pretty equal in features - components, >>> >> technology neutral, >> >>> validation, binding, etc. >>> >>> Now I wonder why I should prefer Cocoon Forms over JSF. I >>> >> don't need >> >>> continuations, so Flow doesn't matter to me. >>> >>> The most important thing I figured so far is: With JSF, the >>> >> output is >> >>> always serialized to text, whereas Cocoon Forms can be part >>> >> of the SAX >> >>> event pipeline. So with JSF I would need to parse the >>> >> output again if >> >>> I want to transform the generated XML. >>> >>> Am I correct? >>> >>> With best regards, >>> Christian Schlichtherle >>> -- >>> Schlichtherle IT Services >>> Wittelsbacherstr. 10a >>> 10707 Berlin >>> >>> Tel: +49 (0) 30 / 34 35 29 29 >>> Mobil: +49 (0) 173 / 27 12 470 >>> mailto:[EMAIL PROTECTED] >>> http://www.schlichtherle.de <http://www.schlichtherle.de/> >>> >>> >> --------------------------------------------------------------------- >> 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] -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
