You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Christian Schlichtherle <ch...@schlichtherle.de> on 2007/06/04 12:17:57 UTC
Cocoon Forms vs. JSF
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:christian@schlichtherle.de
http://www.schlichtherle.de <http://www.schlichtherle.de/>
RE: Cocoon Forms vs. JSF
Posted by Derek Hohls <DH...@csir.co.za>.
Christian
But we are in the business of XML... and getting to grips
with a (relative simply) new schema is hardly a "new technology".
And Javascript is probably the most commonly used language
on the web. I can't agree these represent a major learning
curve.
But we digress from the topic. I would certainly like to learn more
about how JSF compares and operates. Each new idea can
spark off others - as per this quote from Peter Norvig:
"Homogeneity is great for milk, but not for ideas."
http://www.norvig.com/lancet.html
Derek
>>> "Christian Schlichtherle" <ch...@schlichtherle.de> 2007/06/04
04:56:23 PM >>>
Hi,
> 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...
Wait a minute - a form definition uses a different XML schema than the
view
template and the sitemap and the Flowscript is even an entirely
different
language. That's a mix of four schemes/grammars for one form and you
have to
know all of them.
Kind regards,
Christian
--
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Forms vs. JSF
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
Hi,
I do know XSL/T, but that doesn't help with the Schema of any input to the
XSL processor.
Kind regards,
Christian
Re: Cocoon Forms vs. JSF
Posted by Baptiste Placé <bo...@free.fr>.
Hi,
Maybe you are still learning parts of xml/xslt, or you are just new to
cocoon, but what is saying Florian is one unavoidable aspect of
programming : be resistant against changes for the better.
Moreover, pipelines should not be duplicated with widlcard/regexp :)
Baptiste
Christian Schlichtherle a écrit :
> Hi,
>
>
>> 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...
>>
>
> Wait a minute - a form definition uses a different XML schema than the view
> template and the sitemap and the Flowscript is even an entirely different
> language. That's a mix of four schemes/grammars for one form and you have to
> know all of them.
>
> Kind regards,
> Christian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Forms vs. JSF
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
Hi,
> This is because they describe different aspects of a form.
I appreciate this well (otherwise I wouldn't use Cocoon), but just wanted to
make clear that XML by itself is little more than a string tokenizer.
Without a DTD, Schema, or RELAX NG and the implied semantics an XML file
says nothing - not to a human and not to a machine.
I understand "Separation of Concerns" very well (this concept is not a
Cocoon invention), but I also think that I have to be careful not to do
"Disintegration into Irresponsibility" with my app.
Anyway, I give up my resistance and go on with Cocoon Forms. Now I'm
assimilated by the Cocoon Borg. :-)
Kind regards,
Christian
Re: Cocoon Forms vs. JSF
Posted by Alexander Klimetschek <al...@mindquarry.com>.
I personally like the features of Cocoon Forms and the easy flow with
continuations, but I see the problem of two many files for a single form as
well. And if you don't need continuations then the advantages of Cforms melt...
One of the key concepts of CForms is to be output-format neutral: so it
could be HTML (Forms) and... ehm... wait... XForms... And that's the problem
when you only work with HTML (and I'd be interested to hear if someone doing
something else) - the overall "pipeline" gets very long:
Flowscript
Data (maybe XML)
Form Binding (standard/Java code)
Form Definition (XML)
Form Template (XML with a bit of HTML)
Form Instance (XML - you don't write it, but you need to know it for
matching in the stylesheets below)
form2html standard stylesheet (XSL)
form2html custom stylesheet
(some html2html general stylesheet for your app)
So if you care about your user interface and want to tweak the HTML code
that gets produced, you have quite a hard time figuring out how to write
your form2html custom stylesheet. And often I sit there and have to think
quite a while to make the decision where to put stuff. For example you often
put HTML into the form template - but sometimes this could be put into the
form2html as well.
And finally I practically see little value in splitting definition and
template - the cases where you re-use your definition in multiple templates
are very very few - and that's the only reason for the split up AFAIK, apart
from general abstraction of the data model. But you probably have two data
model abstractions anyway: in your Java code and/or in your database scheme.
Ok, enough rant, continuations, validation, javascript action handlers and
ajax on/off are very good features ;-)
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Forms vs. JSF
Posted by Dev at weitling <de...@weitling.net>.
>> 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...
>>
>
> Wait a minute - a form definition uses a different XML schema than the view
> template and the sitemap and the Flowscript is even an entirely different
> language. That's a mix of four schemes/grammars for one form and you have to
> know all of them.
>
Well, hm :-)
This is because they describe different aspects of a form. i.e. the
definition (what kind of data is hold and how is it validated), the
template (how is the data presented) and the binding (which model field
corresponds to which form field for loading and saving). But
nevertheless they are all processed with XSL-T.
It would be easier to have a kind of automagic form file generator. But
for most purposes it's more work in typing than in thinking when
creating these files ;-)
And the sitemap is for getting the right chain/pipeline to a request may
it be sent from outside or inside (getting those
definition/template/binding-files).
As I said: It seems more work to split it up in those myriad of files
but if you see it all mixed up like in JSP...
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Forms vs. JSF
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
Hi,
> 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...
Wait a minute - a form definition uses a different XML schema than the view
template and the sitemap and the Flowscript is even an entirely different
language. That's a mix of four schemes/grammars for one form and you have to
know all of them.
Kind regards,
Christian
Re: Cocoon Forms vs. JSF
Posted by Derek Hohls <DH...@csir.co.za>.
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 <de...@weitling.net> 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:Ralph.Goers@dslextreme.com]
>> Sent: Monday, June 04, 2007 3:27 PM
>> To: users@cocoon.apache.org
>> 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:christian@schlichtherle.de
>>> http://www.schlichtherle.de <http://www.schlichtherle.de/>
>>>
>>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
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
CallCentre@csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Forms vs. JSF
Posted by Dev at weitling <de...@weitling.net>.
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:Ralph.Goers@dslextreme.com]
>> Sent: Monday, June 04, 2007 3:27 PM
>> To: users@cocoon.apache.org
>> 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:christian@schlichtherle.de
>>> http://www.schlichtherle.de <http://www.schlichtherle.de/>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon Forms vs. JSF
Posted by thomason <th...@physio1.utmem.edu>.
on 6/4/07 8:52 AM, Christian Schlichtherle at christian@schlichtherle.de
wrote:
> + 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.
I don't find it nearly so daunting. The samples show good examples of
pipeline reuse (for concise coding). So all templates can go through a
*_template pipeline, all bindings through a *_bind pipeline, etc. The
controller logic can be a single function to handle all forms.
For example:
<!-- bind existing data to an editable form. The call is
director.protocol#.section.sheet.bind
The bindform is in the forms directory and has the name
'sheet'_bind.xml -->
<map:match pattern="*.*.*.*.bind">
<map:call function="handleForm">
<map:parameter name="function" value="formedit"/>
<map:parameter name="definitionURI" value="forms/{4}.xml"/> <!--model-->
<map:parameter name="bindingURI" value="cocoon:/bindtemplate.{4}.{2}"/>
<map:parameter name="validateURI" value="{1}.{2}.{3}.{4}.validate"/>
<!-- return here until controller detects flag condition -->
<map:parameter name="returnURI" value="{1}.{2}.{3}.{4}.bind"/>
... other named parameters
</map:call>
</map:match>
<!-- binding template to bind the data to the form. The call is
bindtemplate.bindform.protocol#
The bindform is in the forms directory and has the name
'bindform'_bind.xml -->
<map:match pattern="bindtemplate.*.*">
<map:generate src="forms/{1}_bind.xml"/> <!-- binding -->
... transform the binding, if needed
<map:serialize type="xml"/>
</map:match>
<!-- ShowPageAndWait pipeline to validate data. The call is from the binding
flowscript in the form director.protocol#.section.sheet.validate -->
<map:match pattern="*.*.*.*.validate">
<map:generate src="cocoon:/formtemplate.{../4}.{../2}" type="newjx"/>
<map:transform type="browser-update"/>
<map:transform type="forms"/>
... styling and other transformations
<map:select type="ajax-request">
<map:when test="true">
<map:serialize type="xml"/>
</map:when>
<map:otherwise>
<map:serialize type="html"/>
</map:otherwise>
</map:select>
</map:match>
<!-- pipeline to process the form template. The call is
formtemplate.form.protocol#
The form is in the forms directory and named 'form'_template.xml -->
<map:match pattern="formtemplate.*.*">
<map:generate src="forms/{1}_template.xml"/> <!-- template -->
... transform the template, if needed
<map:serialize type="xml"/>
</map:match>
I have use this strategy to process dozens of forms. Presumably, each of
your 10 forms has different data, so generating models, bindings, and
templates will have to be unique (unless there is enough similarity to
process it through a pipeline, as above).
Best,
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon Forms vs. JSF
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
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:Ralph.Goers@dslextreme.com]
> Sent: Monday, June 04, 2007 3:27 PM
> To: users@cocoon.apache.org
> 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:christian@schlichtherle.de
> > http://www.schlichtherle.de <http://www.schlichtherle.de/>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: Cocoon Forms vs. JSF
Posted by Ralph Goers <Ra...@dslextreme.com>.
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:christian@schlichtherle.de
> http://www.schlichtherle.de <http://www.schlichtherle.de/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org