You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/05/03 22:19:20 UTC
Re: Cocoon context "incomplete"
Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:
> For putting ServerFaces and Cocoon together a friend of mine (Claas
> Thiele, you might know him) needs the Cocoon context to provide some
> more methods of the ServletContext.
>
> http://sourceforge.net/tracker/index.php?
> func=detail&aid=932342&group_id=89524&atid=590402
> http://cvs.sourceforge.net/viewcvs.py/patchwork/xfaces/src/
> org/ct42/xfaces/faces/context/CocoonExternalContext.java
>
> WDYT?
If no one objects I will add the missing methods to the HttpContext, so that we
can at least down cast to the needed context object. I will wait 3 days.
Joerg
Re: Cocoon context "incomplete"
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-05-05 at 16:32, Stefano Mazzocchi wrote:
<snip/>
> > Comparing JSF and CForms in deep there are some fundamentals missed in
> > CForms:
> > - Clean separation of state management
>
> that's because you can't take CForms and move it outside the context of
> the cocoon framework. JSF draws from the experience of Struts, but it
> was designed to run without it (JSR spec lead is the author of Struts).
> CForms doesn't draw on the experience of cocoon and tries to replace it.
The 'it' in the last sentence refers to Struts, right?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Cocoon context "incomplete"
Posted by Stefano Mazzocchi <st...@apache.org>.
Joerg Heinicke wrote:
> As I'm not yet really involved in this JSF integration project, I
> forwarded your mail and here are the answers by Claas. I copied them out
> of his mail (untouched) as this mail contained my German text inside.
> Find the answers below.
>
> Joerg
>
> On 03.05.2004 23:47, Sylvain Wallez wrote:
>
>> Adding this method on HttpContext doesn't hurt in any way, since it
>> doesn't change the interface shared with other Context implementations.
>>
>> So +1 for this.
>>
>> Now the question is to know if JSF can work outside of the servlet
>> environment. If this is the case, you may also want to change the
>> Context interface also. But this would require a vote because it's an
>> incompatible change for people having written their own environments
>> (not sure there aren't that much though).
>
>
> Yes JSF can do, and that is what I want. So enhancing the Context
> Interface would be the right way (and the only one makes sense).
>
> I can work around this problem by falling back to the original
> ServletContext for missing methods, but thats not clean and confine the
> usefulness in non-servlet environments.
> I think, this does not depend on JSF integration. It will be a good idea
> for Cocoon having a most complete Context.
>
>> BTW, why integrate JSF and Cocoon when we have CForms?
>
>
> Thats the question I'm awaited for....
> At first: JSF is a framwork and a spec supported by industry more than
> CForms. This does not state everything about the today's quality of the
> compared technologies. But JSF will evolve faster and will be more
> stable and more complete due to the larger 'community'.
ROTFL! This is exactly the opposite: a larger industrial community tends
to have huge inertia (see how bad JSP are) and do several mistakes
driven by back compatibility reasons (see Servlet Filters vs. cocoon
pipelines).
> Comparing JSF and CForms in deep there are some fundamentals missed in
> CForms:
> - Clean separation of state management
that's because you can't take CForms and move it outside the context of
the cocoon framework. JSF draws from the experience of Struts, but it
was designed to run without it (JSR spec lead is the author of Struts).
CForms doesn't draw on the experience of cocoon and tries to replace it.
> - Separation from underlying technologie (not servlet dependent)
same here
> - Separation of navigation handling, validation, and application binding
> For all this things the JSF spec defines interfaces and/or describes
> contracts so third parties can develop here own things with future
> proving of investment.
> At this time there is no much implemented better than CForms had. But it
> will be...
Oh sure. Industry is stupid enough to buy anything that has a
JCP-organic logo on it. Proof in point, they bought JSP for years and
now JSP2 is cloning Velocity. Wait to go!
> Second: Such a complex technology needs tool support, integration in an
> IDE and so on. With a larger market of the base technology this things
> will come...
> On the other hand:
>
> In my opinion there is a a big disadvantage of JSF:
> They define Java classes as renderers.
> Building up a complete and reliable Renderkit supporting different
> browsers is one of the main points overall.
The Renderkit idea is simply flawed. These guys don't know what real
multichanneling is. they think multichanneling is not one channel, it's
two, or three. Cocoon power users know that multichanneling is about
hundreds of channels.
Think about the maintenance cost of 150 renderkits written in java
versus a hierarchy of xslt stylesheets.
> But: The web designer cracks (knowing all about the browser quirks) are
> in most cases not the java cracks. They can not build up a complex,
> reusable and maintainable renderkit written in java.
bingo, xslt is hard enough for them, but it's definately less expensive
than java code in those situations.
> At all it will be the wrong way making complex things for a markup based
> client (like HTML, XUL, WML, ...) in Java. You will feel the dejavue
> looking on some JSP pages and the growing taglibs behind.
Exactly!
> So lets Cocoon render and let us use all the other things coming up with
> JSF like complex state holding, complex application binding, tools
> support and so on.
>
> Thats the main goal of PatchWork.XFaces.
I think that using JSF for nothing related to the faces is, well, rather
peculiar. I think you'll find out that CForms+sitemap+flow is *way*
better than anything else you can throw at it.
Sure, you have to give up the JCP-organic brand. Live dangerously. It's
a state of mind, actually, nothing technological. Not everybody can do that.
> ...And: Competition stimulates the Business
Competition? I, for one, never felt the competition of JSF, they spent
years in a JCP ivory tower to standardize Struts while everybody knows
that multichanneling is a completely different business.
In the long run, good solutions win, not good marketing engines.
--
Stefano.
Learning more about JSF and CocoonForms (was: Re: Cocoon context
"incomplete")
Posted by Reinhard Poetz <re...@apache.org>.
Any JSF gurus: Pls don't feel offended by my remarks - I only want to
learn more about the pros and cons of both frameworks!
> Thats the question I'm awaited for....
> At first: JSF is a framwork and a spec supported by industry more than
> CForms. This does not state everything about the today's quality of the
> compared technologies. But JSF will evolve faster and will be more
> stable and more complete due to the larger 'community'.
> Comparing JSF and CForms in deep there are some fundamentals missed in
> CForms:
> - Clean separation of state management
What is JSF doing _exactly_ better than CocoonForms in this respect?
> - Separation from underlying technologie (not servlet dependent)
Isn't this true for CocoonForms too?
(Anyway, I think it's a rather academic point, isn't it?)
> - Separation of navigation handling, validation, and a
CocoonForms does *not* include the controller. It uses Flowscript for this.
> aplication binding
CocoonForms has a bindings framework which is IMHO more flexible than JSF
> For all this things the JSF spec defines interfaces and/or describes
> contracts so third parties can develop here own things with future
> proving of investment.
CocoonForms has many of those interfaces too ...
> At this time there is no much implemented better than CForms had. But it
> will be...
Let's see ... ;-)
>
> Second: Such a complex technology needs tool support, integration in an
> IDE and so on. With a larger market of the base technology this things
> will come...
I already saw a very promising screenshot of an upcoming CocoonForms
plugin for Eclipse ...
The problem is that you have to decide whether you want an abstract
framework which makes it really difficult or impossible to develop
WYSIWIG tools or if you want something like Tapestry where you have
standard HTML which contains information about server-side components.
The current JSF implementation only contains an HTML render kit and so
it is possible to write WYSIWIG tools. But if I understand your approach
correctly you want to produce XML and then I'm not sure any more what
will happen with tool support.
The remaining question to answer is, which alternative is in the *long*
run (including maintaince cost) the better (cheaper) one.
> On the other hand:
>
> In my opinion there is a a big disadvantage of JSF:
> They define Java classes as renderers.
> Building up a complete and reliable Renderkit supporting different
> browsers is one of the main points overall.
What happens if I want to change the renderer in the code snipped below?
Do I have to "touch" it or not?
<h:inputText id="ccno" size="16"
converter="creditCardConverter" required="true">
<cs:format_validator
formatPatterns="9999999999999999|9999 9999 9999
9999|9999-9999-9999-9999"/>
</h:inputText>
>
> But: The web designer cracks (knowing all about the browser quirks) are
> in most cases not the java cracks. They can not build up a complex,
> reusable and maintainable renderkit written in java.
> At all it will be the wrong way making complex things for a markup based
> client (like HTML, XUL, WML, ...) in Java. You will feel the dejavue
> looking on some JSP pages and the growing taglibs behind.
let me add some more points here:
- I think JSF heavily mixes concerns. You've to write all-in-one pages
(definition, validation, convertors, binding, style). I think this is a
big mess :-(
- Binding is a separate framework and is IMO more flexible.
- You can use pipelines to render Forms which is I guess the reason why
you want to integrate JSF.
- In CocoonForms you have to declare your widgets and then you use them
in your templates. If there is a global widget repository we finally
have a highly reusable solution (e.g. you declare the widget 'customer
number' only once and use it in all the forms where you need it).
- You usually don't need Java code to develop CocoonForms so you have
very fast roundtrip-cylces during development.
> So lets Cocoon render and let us use all the other things coming up with
> JSF like complex state holding, complex application binding, tools
> support and so on.
>
> Thats the main goal of PatchWork.XFaces.
Please keep us informed about your progress!
> ...And: Competition stimulates the Business
>
> Claas
--
Reinhard
Re: Cocoon context "incomplete"
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> As I'm not yet really involved in this JSF integration project, I
> forwarded your mail and here are the answers by Claas. I copied them
> out of his mail (untouched) as this mail contained my German text
> inside. Find the answers below.
>
> Joerg
>
> On 03.05.2004 23:47, Sylvain Wallez wrote:
>
>> Adding this method on HttpContext doesn't hurt in any way, since it
>> doesn't change the interface shared with other Context implementations.
>>
>> So +1 for this.
>>
>> Now the question is to know if JSF can work outside of the servlet
>> environment. If this is the case, you may also want to change the
>> Context interface also. But this would require a vote because it's an
>> incompatible change for people having written their own environments
>> (not sure there aren't that much though).
>
>
> Yes JSF can do, and that is what I want. So enhancing the Context
> Interface would be the right way (and the only one makes sense).
>
> I can work around this problem by falling back to the original
> ServletContext for missing methods, but thats not clean and confine
> the usefulness in non-servlet environments.
> I think, this does not depend on JSF integration. It will be a good
> idea for Cocoon having a most complete Context.
I agree with this. But modifying one of the Environment interfaces can
lead to important compatibility issues, so I would say that for now, we
can add the required methods on HttpContext to solve the problem right
now, and consider changing the environment interfaces.
>> BTW, why integrate JSF and Cocoon when we have CForms?
>
>
> Thats the question I'm awaited for....
;-)
> At first: JSF is a framwork and a spec supported by industry more than
> CForms. This does not state everything about the today's quality of
> the compared technologies. But JSF will evolve faster and will be more
> stable and more complete due to the larger 'community'.
Mmmh... this argument is not relevant for me: JSF is designed by a JSR
team, and although I don't know how are things going in this team, JSR
teams often are driven by political fights between the different
participating companies.
> Comparing JSF and CForms in deep there are some fundamentals missed in
> CForms:
> - Clean separation of state management
Uh? Can you elaborate on this? CForms has a very clear separation
between form state (the widgets), application state (flowscript) and
page rendering. I don't see such a thing in JSF where form definition
and page template are mixed.
> - Separation from underlying technologie (not servlet dependent)
CForms doesn't rely in any way on servlets. It uses Cocoon's Request
object which abstracts the actual environmnent.
> - Separation of navigation handling, validation, and application binding
Uh (again)? How navigation is handled is not a concern of the Form, but
that of the FlowScript, and application binding is defined in a separate
binding file, contrarily to JSF where the page template contains both
the widget definition and the binding to the application model.
> For all this things the JSF spec defines interfaces and/or describes
> contracts so third parties can develop here own things with future
> proving of investment.
> At this time there is no much implemented better than CForms had. But
> it will be...
I don't buy that: CForms defines interfaces and components that provide
entry points for any additional feature that could be required.
> Second: Such a complex technology needs tool support, integration in
> an IDE and so on. With a larger market of the base technology this
> things will come...
Aha : "such a complex technology"! Yep, CForms has a simpler
architecture, yet is very powerful. Bloated specs require IDEs, while
slim and clean ones only require productivity tools. And such tools will
come (yep, got some prototype running on my laptop).
> On the other hand:
>
> In my opinion there is a a big disadvantage of JSF:
> They define Java classes as renderers.
> Building up a complete and reliable Renderkit supporting different
> browsers is one of the main points overall.
Yep, that's one of the first things that made my hair raise on my head
when reading the JSF spec: to write a renderkit, we're back to the old
pre-jsp out.println("<html>") days...
> But: The web designer cracks (knowing all about the browser quirks)
> are in most cases not the java cracks. They can not build up a
> complex, reusable and maintainable renderkit written in java.
> At all it will be the wrong way making complex things for a markup
> based client (like HTML, XUL, WML, ...) in Java. You will feel the
> dejavue looking on some JSP pages and the growing taglibs behind.
Exactly. And this also means that JSF makes it practically impossible to
write a multi-channel application relying on the same form definition :
each renderkit will define its own markup, and as page template and
definition are mixed within a JSP, this means one different Form for
each channel.
With CForms, you have:
- a single form definition
- possibly a single template, if written in a markup that abstracts the
different channels
- several XSLT renderings, selected depending on the target channel or
browser.
> So lets Cocoon render and let us use all the other things coming up
> with JSF like complex state holding, complex application binding,
> tools support and so on.
So you want to implement a RenderKit in Cocoon? Good idea. Now have you
really looked at how Cocoon and FlowScript can handle complex state
management. It's so easy that you can be nearly as creative as with a
fat client. With some of my latest webapps, I saw people used to
"traditional" webapp development (read Struts) that couldn't believe
what they saw on screen, and got crazy when they saw this was just a few
CForms and a dozen lines of flowscript.
Yes, Cocoon/CForms/FlowScript makes JSF really an old-fashioned obsolete
thing before it's even born. But I'm biased of course ;-)
> Thats the main goal of PatchWork.XFaces.
>
>
> ...And: Competition stimulates the Business
Sure, but the question is: will people continue using JSF once Cocoon
will have infected their app? In this regard, PatchWork.XFaces is a very
good marketing tool for CForms and Cocoon in general. So keep up the
good work ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon context "incomplete"
Posted by Joerg Heinicke <jo...@gmx.de>.
As I'm not yet really involved in this JSF integration project, I
forwarded your mail and here are the answers by Claas. I copied them out
of his mail (untouched) as this mail contained my German text inside.
Find the answers below.
Joerg
On 03.05.2004 23:47, Sylvain Wallez wrote:
> Adding this method on HttpContext doesn't hurt in any way, since it
> doesn't change the interface shared with other Context implementations.
>
> So +1 for this.
>
> Now the question is to know if JSF can work outside of the servlet
> environment. If this is the case, you may also want to change the
> Context interface also. But this would require a vote because it's an
> incompatible change for people having written their own environments
> (not sure there aren't that much though).
Yes JSF can do, and that is what I want. So enhancing the Context
Interface would be the right way (and the only one makes sense).
I can work around this problem by falling back to the original
ServletContext for missing methods, but thats not clean and confine the
usefulness in non-servlet environments.
I think, this does not depend on JSF integration. It will be a good idea
for Cocoon having a most complete Context.
> BTW, why integrate JSF and Cocoon when we have CForms?
Thats the question I'm awaited for....
At first: JSF is a framwork and a spec supported by industry more than
CForms. This does not state everything about the today's quality of the
compared technologies. But JSF will evolve faster and will be more
stable and more complete due to the larger 'community'.
Comparing JSF and CForms in deep there are some fundamentals missed in
CForms:
- Clean separation of state management
- Separation from underlying technologie (not servlet dependent)
- Separation of navigation handling, validation, and application binding
For all this things the JSF spec defines interfaces and/or describes
contracts so third parties can develop here own things with future
proving of investment.
At this time there is no much implemented better than CForms had. But it
will be...
Second: Such a complex technology needs tool support, integration in an
IDE and so on. With a larger market of the base technology this things
will come...
On the other hand:
In my opinion there is a a big disadvantage of JSF:
They define Java classes as renderers.
Building up a complete and reliable Renderkit supporting different
browsers is one of the main points overall.
But: The web designer cracks (knowing all about the browser quirks) are
in most cases not the java cracks. They can not build up a complex,
reusable and maintainable renderkit written in java.
At all it will be the wrong way making complex things for a markup based
client (like HTML, XUL, WML, ...) in Java. You will feel the dejavue
looking on some JSP pages and the growing taglibs behind.
So lets Cocoon render and let us use all the other things coming up with
JSF like complex state holding, complex application binding, tools
support and so on.
Thats the main goal of PatchWork.XFaces.
...And: Competition stimulates the Business
Claas
--
____________________________________________________________________
Dipl.-Inf. Claas Thiele EMail: cthiele<at>ct42.de
Konradstr. 58 Web: http://ct42.de
04315 Leipzig Tel.: +49 (0)341 68 70 92 29
GERMANY Fax +49 (0)341 68 70 92 30
Re: Cocoon context "incomplete"
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
>Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:
>
>
>
>>For putting ServerFaces and Cocoon together a friend of mine (Claas
>>Thiele, you might know him) needs the Cocoon context to provide some
>>more methods of the ServletContext.
>>
>>http://sourceforge.net/tracker/index.php?
>>func=detail&aid=932342&group_id=89524&atid=590402
>>http://cvs.sourceforge.net/viewcvs.py/patchwork/xfaces/src/
>>org/ct42/xfaces/faces/context/CocoonExternalContext.java
>>
>>WDYT?
>>
>>
>
>If no one objects I will add the missing methods to the HttpContext, so that we
>can at least down cast to the needed context object. I will wait 3 days.
>
>
Adding this method on HttpContext doesn't hurt in any way, since it
doesn't change the interface shared with other Context implementations.
So +1 for this.
Now the question is to know if JSF can work outside of the servlet
environment. If this is the case, you may also want to change the
Context interface also. But this would require a vote because it's an
incompatible change for people having written their own environments
(not sure there aren't that much though).
BTW, why integrate JSF and Cocoon when we have CForms?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }