>The simplest way people have done this in the past is to wrap the
>request/response using a Servlet filter placed in front of the
>FacesServlet. You're going to have a tough time doing it without at
>least starting the process this way because the JSF runtime makes a lot
>of assumptions that it's running in a Servlet container via HTTP.
We are using the same approach you mention here.
I was looking for confirmation that our approach is the most practical in current stage of JSF.
And you have provided it. Thank you for that!
But the most important thing you have said that JSF has architecture very much oriented around Servlet.
Those words put my thoughts in very different direction.
First of all, now I understand that is impossible with small tweak in JSF implementation to resolve the issue.
Second, I believe that now is the most important thing is relax as much as possible strong dependency architecture of JSF from Servlet lifecycle.
Starting from eliminating direct dependency between rendering engine and Servlet life cycle perhaps is the best way to make quick and big impact in this direction.
LB> Otherwise you probably still need to run a JSF server, then use an HTTP
LB> client to send requests in order to capture the output. I agree with Martin
LB> -- look at Apache Velocity or something of that nature.
Implementing decoupling jsf rendering engine from servlet lifecycle could provide possibility to use JSF with other template engines.
Who knows maybe some developers would prefer to use Velocity as main rendering force for JSF.
LB> An extension to JSF could do this? Yes. Has it been done? No. I'm
LB> sure a lot of people would love you if you got something working ;)
LB> Including myself.
As you can see from this comment there are many people who have interest to change something in this area.
It would be good if everybody who needs some changes describe the exact reason why they would benefit in case rendering process disconnect from JSF lifecycle.
(Probably there is a need to reformulate the question)
If you get number of reasons you will have more ground to design more precisely the future strategy.
>I do know that people have made it so JSF renders to PDF. But, again,
>this was kicking off the process via the Servlet request/response flow.
This is a perfect case. In many cases we need to render exactly the same report/page but in different from HTML format.
Usually this is PDF but could be something else.
To implement PDF rendering usually apply some kind of converter that can transform HTML to PDF.
So in case to use the converter we need direct access to result of HTML rendering.
Often PDF result must go instead of browser to email box.
It would be fun to have a possibility to use redirect process not only for browser but for email, atom and other communications means :)
In this situation ideal solution would be to have almost the same business logic for handling different types of rendering.
>I've said time and again that JCP specifications are emphatically *not*
>the places to invent stuff. We tried that with JSF 1.0 and we're still
>trying to live it down. Rather, they should standardize existing,
>proven, best practices in a way that maximizes the cohesion of the
>entire Java platform.
I understand your point and I’m ready to agree with it but there are a couple of issues with this approach.
What to do if some of the best, proven and existing practices established outside the Java world.
What to do when Java are losing market share to PHP and Ruby especially in area of web applications and JCP traditionally was the main driving force in area of innovations for Java World.
> I'm proud of the work we've done with JSF 2.0 in this regard.
No doubt here that in general strategy for JSF 2.0 was defined correctly and executed properly.
All main issues have been resolved on this stage.
Many people including myself are thankful for it.
>1. Metamorfaces. I've been working with a gentleman in Senegal on his
>ideas to create a Joomla! like technology built on top of JSF.
There are at least 1700 content management systems on the market.
In fact every single company has to use some kind of CMS.
For now PHP based CMS such as Wordpress, Joomla and Drupal dominate the market place.
The main requirement for CMS is to be very flexible and adaptive system.
Question is if JSF up to this task without taking too much effort from developers such system.
I’m not sure about it.
To be honest I’m planning to develop CMS very soon with my team and already have started to read a couple books on this topic.
The books describe in very clear manner how to create PHP based CMS.
Follow the books and it should be very easy to adapt their insight to JSF based system.
I’m talking so much about CMS because I truly believe that JSF team should use CMS as show case instead of Pet Store.
Definitely it's time to start doing less “pety” kind of examples :)
For today’s market we need something more mature.
If you like the idea to create CMS as show case for JSF advertisement I could help to implement it.
For example prepare specification or design database structure and so on. Of course I’m talking about creating mini kind of CMS.
The perfect name for it would be “Jungla” :) Instead of petit size animals such as cats or dogs it’s time to have lion's and tiger's faces as symbol JSF power.
Regarding Metamorfaces I'm going to dig there.
>2. RooFaces. I've been working with a friend here in Orlando to provide
>a Roo add-on that enables Roo to generate JSF2 pages.
Probably it’s not that bad idea to use JSF rendering mechanism as tools to generate source code.
>This is a great idea, particularly now that the JSF spec is lead by a
>company with more resources they could devote to JSF than Sun.
I really glad that you like the idea. You are practical man so my hope is that you will be able somehow to implement it.
To improve chances to get more resources for JSF developing its good tactic to be more proactive.
I suggest that you draw very ambitious plan and start asking for resources.
Here are the reasons why JSF world benefit from decoupling Template Engine from Servlet life cycle.
1)Testing (FacesTester project as example)
2)Validating rendering result before going online
3)PDF rendering
4)Rendering interchange messages such as X12, HL7 and so on
5)More flexible and complete solution for rendering non-HTML clients such as SVG, XUL, X3D and so on, comparing to RenderKit.
6)Rendering JSON and JavaScript (Frisco JSF additions as example, rise level of usage JavaScript frameworks)
7)Source Code generation (including generation code on the fly)
8)Rendering ORM.xml(JPA entities), business rules(MVEL)
9)Access and Control improvements
10)Navigation Flow improvements
11)Pluggable rendering/template engine (possibility to use Velocity, JavaScript based template engine and so on)
12)Possibility to use Servlet replacement such as JSGI
13)Higher possibility to use JSF by different frameworks and languages
Thank you for attention!
Vladimir
[Message sent by forum member 'vladperl' (vladperl_at_hotmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=388046