|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 314
Messages: 314
Messages: 314
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tim Shadel says JSF isn't their choice for the future
Tim Shadel, in a podcasted talk linked to from "JSF: The 7-Layer Burrito I Won't Eat Again," says that after using JavaServer Faces for months, they've decided that they wouldn't use JSF in the future. The primary reason? JSF uses POST, not GET, and as a result, links to specific aren't conversational state isn't preserved, unlike with REST.
In the podcast, he says that the URL hiding affects JSF from start to finish. While he says JSF may be all right for applications that use internal state, it will be awful for applications that should expose content urls to, say, search engines – like blogs or other content applications. Further, the URL hiding affects deployment, because applications can't refer to other applications' states.
The JavaServer Faces specification does indicate that POST is used exclusively; the form tag doesn't define a pass-through attribute for "method" to allow use of GET, and while it may be possible to create a render kit for JSF that enables use of alternate methods, this seems like a strange requirement for application developers. However, a quick search on Google does show a few examples of embedding data in a URL for use in JSF.
Of further interest is the note that this is the "first of a long list of reasons why the JSF 7-layer burrito won't be on my round for seconds."
What are your experiences and opinions about this? Is this a critical limitation of JSF? Would this affect your willingness to adopt JSF in public-facing applications? Why or why not?
|
Threaded replies
| · |
sure
by
t mc
on Thu Jan 19 14:19:21 EST 2006
|
|
|
Message #197670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
It's quite strange to say JSF isn't the choice for the future basing on past experience. I would say that JSF 1.1 isn't fully prepared and flexible enough for production, but we should wait for 1.2 and then make conclusions about the future. I believe JSF will evolve significally, the graphic tools for JSF will evolve too, it's powerful framework with great potential. Too early to throw JSF out.
|
|
|
Message #197671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lack of POST not a 'show stopper'
I've never found the POST requirements to be a true limitation. You can always get to the core Servlet response/request stuff when you need it for legimate uses of URL parameters. I think that people who are stuck on the use of POST simply haven't crossed the bridge from the older web frameworks that are based heavily on response/request. You just need to re-think how you're trying to solve your problem.
|
|
|
Message #197672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
The technical problems and dislikes that Tim Shadel describes about JSF are really just an example general problems with JSF. It seems everyone has issues with the technology.
JSF has not got market traction (let alone critical mass) with the Java developer community.
And THAT is the reason why it's not the choice for the future.
PJ Murray
CodeFutures Software
Code Generation for Java Persistence
|
|
|
Message #197677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Mostly Agree w/r/t POST issues...
There are some definite (and fairly easy) ways to get around that limitation for sites that need to be Search Engine friendly.
Having said that, those techniques should be formalized, and JSF does a poor job of supporting them out of the box.
|
|
|
Message #197686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lack of POST not a 'show stopper'
I've never found the POST requirements to be a true limitation. You can always get to the core Servlet response/request stuff when you need it for legimate uses of URL parameters.
I agree that this may not be a show stopper, but I think this kind of simple requirement SHOULD BE addressed by the framework. It is quite a simple and common requirement. Other framework address this nicely: For example in Tapestry it has ExternalPage for bookmark link, there are even option for you to design your own URL pattern (in T4) (very much like the apache mod_rewrite module).
But of course, this is not the only reason why I don't use JSF, there are lots of little things here and there that just make people hard to develop, not make it easier.
|
|
|
Message #197689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I am sorry
but who is Tim Shadel? I tried to google him but not much came up. Any info will be appreciated.
|
|
|
Message #197690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
External page
Actually having a difference between commandLink and ouputLink in jsf makes this difference as well.
CommandLinks can be seen as internal links while outputlinks can be seen as external links which are bookmarkable.
There are numerous issues like this why people dismiss jsf, although the things are usually there.
|
|
|
Message #197694
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Mr. Shadel
Tim Shadel is a developer here in the Phoenix area.
http://www.timshadel.com
He podcasts his opinion semi-regularly on various dev related stuff.
I worked with him in the recent past on the project of which JSF was being used. I have since moved on to greener pastures. :)
|
|
|
Message #197697
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Matt Raible's JSF experience
In Tim Shadel's post, he indirectly links to Matt Raible's JSF experience, in which Matt begins with:
Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's *not* the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify web development.
Tim also links to David Geary's response to Matt.
Interesting stuff about JSF.. one thing's for sure it doesn't seem to be getting unanimity..
Frederic
|
|
|
Message #197698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.
So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
|
|
|
Message #197699
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Pertaining to Restful state issues with JSF, read:
http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html
Maybe one can complain about the JSF lifecycle, but in reality, there's a lot of good pieces in there that can be tweaked in the future.
And you can't necessarily blame JSF for stateful issues-- everyone has problems with things like open session/transaction in view with working in any session-scoped data, no matter what framework.
-- Jacob
|
|
|
Message #197700
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.
|
|
|
Message #197701
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?
|
|
|
Message #197703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Simply don´t use it if you don´t like it
I don´t know what is happening but this type of POST is becomming very constant in the last few months and I have an strong opinion about JSF, it´s a new technology, a new approach in web development to the JEE community and every java developer need to LEARN before kick it. I was working with JSF about a year and I LIKE IT!!! Yes there are problems with the specification but many of the issues are being resolved in the 1.2 release. All the problems that I found have an workaround LIKE ANY OTHER FRAMEWORK!!!
I think that many of the rejection on JSF is because IT IS VERY CLOSE TO ASP.NET and people don´t like MS, but good things need to be used and MS do a great job on the ASP.NET IMHO.
If you don´t like JSF don´t use it, but don´t try discourage other people that want to learn a new technology.
Sorry for my poor english...
|
|
|
Message #197704
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
It seems everyone has issues with the technology. JSF has not got market traction (let alone critical mass) with the Java developer community.
These are strong statements. Have you evidence for them in terms of developer surveys or reports other than this one? Or are they just opinion?
|
|
|
Message #197705
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!?
If you would have bothered to listen to the podcast, you would have learned Tim had just finished using JSF for 9 months or so in several projects, but I guess you are just one of those people that found something to latch on to so you can comment and whine a little...
|
|
|
Message #197707
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
I keep seeing people flaming JSF maybe because it is supported by a standard who knows. But I rarely technical or design arguments justifying their opinion, seems more like a philosophical issue. A lot of FUD is spread around JSF right now. I have used it for some times now and I must say I like it. There are some issues but overall I enjoys developping it espcially compare to Struts.
I absolutely agree - I think you have got things exactly right. My view is that there is much vocal resistance to JSF simply because it is a JSR specification, and there is a philosphical resistance to 'imposed' standards.
|
|
|
Message #197708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
AJAX could be dismissed also for not making easy to use URLs, and very few people complaint about it. GMail is not bookmarkable, and it is one of the paradigms of a good Internet application.
Although the author says he was developing internal applications, he keeps on putting out Internet examples (Google, del.icio.us). The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works. "This application does not respect the HTTP semantics" does not sound like an argument to a business executive. Web applications are still applications which are supposed to perform useful functions, regardless of whether you can bookmark its state or not. We should think in user terms, not in technological terms.
The author describes how they had to hyperlink two different web applications, and how they had to resort to what he calls "a hack", and that many other people would call just "a workaround". If they are so purist that using such "hack" offends them more than losing the power of a component-based framework, good for them - this alone is not enough for me. The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics. And at any rate, the promise of component based development is well worth of proposing enhancements to the framework to support GET for simple states, instead of throwing it all away. These "7 burrito layers" are pluggable, I think.
JSF has, for more than 3 years, proven unable to achieve enough popularity. 2006 will be its year: either it will be a success, or a definitive failure. It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this. And if the Java world is unable to produce such a framework that is popular to the majority of developers, it will be a shameful failure. And I think it would have more to do with cultural barriers, than with technological ones.
|
|
|
Message #197709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Strange
It is a little bizarre to see in the browsers site bar the URL to a view JSP but be presented content from a completely different view JSP. It just seems that some unwritten fundamental rule of web application design has been violated :)
My beef with JSF is that it doesn't define a security model and there is not a per page view load event.
The only way I found out how to enforce user authentication outside J2EE container security was to build a custom phase listener and enforce authentication there. I didn't think it was a clean solution and since every web application needs authentication it should be clearly defined in the JSF spec.
Also it is difficult to build custom navigation logic on a per view bases before the view is rendered. While navigation based on user events is clearly defined, once a view is selected there is no easy way to forward to a different view if certain conditions were not met.
I believe both of these concerns are suppose to be addressed in JSF 1.2 so I guess I will wait and see.
|
|
|
Message #197712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Philisophical Differences
I have followed JSF much more closely than I would otherwise, precisely because it is a JSR standard. I would prefer to use a web framework that has broad vendor support and competing implementations.
But some of the most damning quotes come from the linked David Geary article.
"I don't think that one of JSF's top priorities is to simplify Web development."
"JSF was designed primarily for use with tools."
"I'm not sure that spending a few days [developing in JSF] is really enough to allow someone to recommend one framework over another."
"Testability is another area that could use some improvement."
He also adds some qualifiers, but these quotes seem to accurately reflect his core position.
If you're going to design a new Web framework, it seems that you can appeal to either of these two camps of developers:
1) Developers who are happy with the functionality of Struts, but would like something easier and faster to work with. Something you can just pick up and be productive with immediately. Simpler to develop with, and simpler to test.
2) Developers who want, first and foremost, more powerful functionality out of their web framework. They are willing to add complexity, develop their own set of helper libraries, invest in specialized toolsets, and sacrifice testability to get the most powerful, extensible framework available. A few days of developing with the framework may be frustrating, but after a few months of experience it won't seem so difficult to work with.
Mr. Geary and his associates have clearly put all their eggs in the #2 basket. This does not seem to be a winning proposition. They seem to be ignoring the fact that frameworks like Spring, Hibernate, and, yes, even EJB3 have gotten a lot of traction with developers by appealing to the #1 mindset.
|
|
|
Message #197713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
AJAX could be dismissed also for not making easy to use URLs, and very few people complaint about it. GMail is not bookmarkable, and it is one of the paradigms of a good Internet application.Although the author says he was developing internal applications, he keeps on putting out Internet examples (Google, del.icio.us). The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works. "This application does not respect the HTTP semantics" does not sound like an argument to a business executive. Web applications are still applications which are supposed to perform useful functions, regardless of whether you can bookmark its state or not. We should think in user terms, not in technological terms.The author describes how they had to hyperlink two different web applications, and how they had to resort to what he calls "a hack", and that many other people would call just "a workaround". If they are so purist that using such "hack" offends them more than losing the power of a component-based framework, good for them - this alone is not enough for me. The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics. And at any rate, the promise of component based development is well worth of proposing enhancements to the framework to support GET for simple states, instead of throwing it all away. These "7 burrito layers" are pluggable, I think.JSF has, for more than 3 years, proven unable to achieve enough popularity. 2006 will be its year: either it will be a success, or a definitive failure. It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this. And if the Java world is unable to produce such a framework that is popular to the majority of developers, it will be a shameful failure. And I think it would have more to do with cultural barriers, than with technological ones.
+1
Not to mention that, in internal business applications, bookmarking pages is exactly what I would rather like prevent. (at least in the most of use-cases I can think of)
I am trying to imagine posting typical Power Substation Sales Configurator page using GET... That would be veeery looong URL! ;-) Oh, and there is nightmare of duplicate posts, too...
|
|
|
Message #197714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
When you say "there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives.", which alternatives did you explore? How deeply?
We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
|
|
|
Message #197715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Funny, I had no trouble creating links, appending parameters to it and processing those parameters on the other side. It was really quite easy. Not sure where the difficulty is on this one. Maybe he got sandboxed by the defaults of a gui.
|
|
|
Message #197716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
"The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works."
"This application does not respect the HTTP semantics" does not sound like an argument to a business executive."
I beg to differ. While many users and executives don't understand these technical details, they *do* want to be able to do things like:
* Bookmark an item on Amazon.com
* Bookmark their eBay auction
* Bookmark an order confirmation page
* Send a link to a blog post or news article via email
That's not to say that POST-only frameworks couldn't support 'bookmarkable items' without GET. I'm not really familiar with JSF. Does it have no support for such a thing?
|
|
|
Message #197717
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GET works in JSF as well
"JSF uses POST" sounds like "JSF does not work with GET". However, it does not true. It is possibe to replace POST with GET and the rest stuff will work the same way. Of course, GET does not allow to send as much data as POST does. It is a browser limitation, but not the JSF fault.
--
Sergey : jsfTutorials.net
|
|
|
Message #197720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
The productivity gains seem much more relevant to me that the purity of the HTTP GET semantics.
Do you have numbers which back up claims of productivity gains? Over what?
It is not that it has to succeed even if proves not good enough, but I hope it is, because experience has shown that using components is the best way to build user interfaces, and web applications are not an exception to this.
Who's experiences? Lots of people disagree with you, me included. At least when you use the term "components" to mean the way JSF manages a big lifecycle and interactions between all of the moving pieces in JSF.
|
|
|
Message #197721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
I've used JSF and have had no problems. There are ways to do what you need, you just have to research. Thats true with anything newish. I have the feeling that Mr. Shadel is just a Blog and Quote type. I wonder if he's really dug deep, or just found something to latch on to so he can blog or podcast about and whine alittle?!? If you would have bothered to listen to the podcast, you would have learned Tim had just finished using JSF for 9 months or so in several projects, but I guess you are just one of those people that found something to latch on to so you can comment and whine a little...
Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!
The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?
I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all!
|
|
|
Message #197723
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
When you say "there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives.", which alternatives did you explore? How deeply? We (major European manufacturing company) are currently finalizing very important application using JSF (MyFaces) and JBoss EJB3. And, once we learned it, it was real pleasure using JSF. Of course, there are some issues, i.e. detecting postbacks, but it was nothing compared to alternatives. Actually, most annoying thing was inability to use lazy relations transparently, but that was not an JSF issue but EJB3 issue. And there is Seam now.So, I believe that most of the negative comments from community are coming just because of the inertia. People approach it with arrogance (oh, I know this, must be like .NET/Struts/<arbitrary_web_framework>) without trying to really understand/learn how this stuff works. And then, they are frustrated that their natural intelligence can not compensate for the lack of information. On the end, it is much easier to say that something sucks than to admit that you were too lazy to go through documentation/samples.
I ment alternative technologies and issues that they have. i.e. ASP.NET.
|
|
|
Message #197724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!
The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?
I am just trying to point out that his generalizations are narrow and that there are different opinions which are also
based on experience. That's all! +1
|
|
|
Message #197725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?
|
|
|
Message #197726
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all!
This is his blog. No one is requiring, or even expecting, you to agree with everything you read on a blog. A blog is someone's opinion, pure and simple. Criticizing someone for expressing their opinion on their own blog seems to miss the point.
|
|
|
Message #197730
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
Did anyone in the JSF community explain why Tapestry was adopted and improved? Why reinvent the wheel?
JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.
|
|
|
Message #197732
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
POST vs GET
IMO, JSF provides perfectly workable support for bookmarkable GET requests.
If you want a link that is a GET request, use:
<h:outputLink value="order.jsf">
<h:outputText value="Take me to my order"/>
<f:param name="orderId" value="#{order.id}"/>
</h:outputLink>
You can then get the paramater value injected to your backing bean using:
<managed-property>
<property-name>orderId</property-name>
<value>#{param[orderId]}</value>
</managed-property>
From my point of view, this is Just Perfect. How could anything be easier?
http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls
OK, so this does not let you process a form submission using GET, but that is something that I rarely ever see people do. Is there really such a burning need to bookmark the results of form submissions?? Is *this* the reason some people won't use JSF??
Certainly, people need post-then-redirect. You can certainly do post-then-redirect using JSF, just use the <redirect> element in the navigation rule, or if you want something fancier call redirect() then responseComplete().
|
|
|
Message #197734
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
Well, I also hate eating fish, although I tried it many times! No good - yuck! The difference is that I won't publish that fact on CNN and expect that rest 6 billion blindly agree with me. though if they would, it could have huge positive impact on ocean ecosystems!The problem is not author's personal opinion. The problem is author's PUBLIC opinion. I would assume that he wouldn't make it public if he expected that everyone would agree, would he?I am just trying to point out that his generalizations are narrow and that there are different opinions which are also based on experience. That's all! This is his blog. No one is requiring, or even expecting, you to agree with everything you read on a blog. A blog is someone's opinion, pure and simple. Criticizing someone for expressing their opinion on their own blog seems to miss the point.
Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS...
|
|
|
Message #197737
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS...
Well, that was a decision by the TSS staff, so don't knock this guy and his blog... I think it was a good decision... Just look at the interesting debates it's sparked already :-)
|
|
|
Message #197738
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
JSF has, for more than 3 years, proven unable to achieve enough popularity.
JSF has not been out that long as a finalized JSR. The final release was 11 March 2004. Many of us are not keen to use things in production use before this stage.
Also, what evidence is there about poor JSF popularity? I have no good way to measure this, except I do see a number of companies investing in JSF components and marketing them, and an increasing number of job offers for JSF developers. I see Oracle donating over a hundred JSF components to open source. I see JSF and JSF-based libraries being highly rated by surveys (OK, these surveys may be questionable, there seems to be a pattern).
I guess JSF success stories aren't as exciting as stories as failures!
|
|
|
Message #197740
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Workarounds for this problem
Great to see that this problem is getting some attention. I first came across it when building a form for an HTML email newsletter. I don't know of any email clients which will actually do a POST - they just seem to launch the browser with the GET url as a command line parameter.
Normally, JSF won't allow you to invoke actions (e.g. from a form submit) when a page is first viewed because it is the last phase in the lifecycle which is responsible for building the component tree. You shouldn't be able to trigger events without the component tree! AFAICT the problem is pretty entrenched into JSF's lifecycle so I don't have my hopes up for seeing it get fixed.
As it happens, there is a workaround, but you need to submit the entire component tree along with the GET url (yeuch!). It is posted amongst other possible solutions at http://forum.java.sun.com/thread.jspa?threadID=586940
|
|
|
Message #197741
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel should try the Taco Supreme!
Well, I couldn't agree more with you! Only, if it stayed his blog and was not published on the TSS... Well, that was a decision by the TSS staff, so don't knock this guy and his blog... I think it was a good decision... Just look at the interesting debates it's sparked already :-)
:o)
At least, It seems that benefits of his post on TSS will exceed the benefits of the content of his post, that's for sure! ;-)
But really, you just need a little bit of eloquence and capability of logical thinking and there you are! You could trash anything in the world! In Sweden is too rainy; in Mauritius you can catch malaria; when it's cloudy it's depressive; when it's sunny you can get skin cancer...
Nothing is perfect, that's clear!
Have fun!
Vlada
|
|
|
Message #197743
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML.
Actually, this is not the reason at all. Tapestry could relative easily be modified to support that feature if it was requested. In fact, it is not hard at all to plug in something like that with HiveMind. The matter is just not requested and is not deemed necessary as a result.
If there is any "incompatibility", it is in the handling of the request cycle, specifically the fully dynamic nature of JSF versus the combined static/dynamic nature of Tapestry. As you know, the ServerSide article on the topic discusses that that issue as well.
There is also the little issue of details such as ease-of-use, error reporting, etc, but this is apparently more subjective than objective.
|
|
|
Message #197744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Workarounds for this problem
Normally, JSF won't allow you to invoke actions (e.g. from a form submit) when a page is first viewed
Right, but 90% of the time you do not need to invoke an action to service a GET request. It is *perfectly* reasonable to have the view "pull" stuff from a backing bean for GET requests. Actions are for "changing stuff". You should not "change stuff" from a HTTP GET, that is not the semantics of GET!
The exception is where this GET request is really a POST in disguise, eg. if you are validating an email address or something. In that case, it is easy enough to hook in a phase listener or something to handle that. Or write a servlet that runs and then forwards to the resulting JSF page. There are many, many reasonable solutions to this. Sure they are workarounds. They are workarounds because *you* are using a workaround, ie. hacking POST semantics into a GET!
Really, it is incredibly trivial to extend JSF to support actions that attach to URLs instead of form submissions. Just look at the PhaseListener API.
|
|
|
Message #197745
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
"The podcast ellaborates about the importance of links, HTTP, URL, REST and web resources. Something about which typical business users are not worried about at all; they just demand that the application works.""This application does not respect the HTTP semantics" does not sound like an argument to a business executive."I beg to differ. While many users and executives don't understand these technical details, they *do* want to be able to do things like:* Bookmark an item on Amazon.com* Bookmark their eBay auction* Bookmark an order confirmation page* Send a link to a blog post or news article via emailThat's not to say that POST-only frameworks couldn't support 'bookmarkable items' without GET. I'm not really familiar with JSF. Does it have no support for such a thing?
Yes, JSF does not block it, it just is that the standard form method is post, but you still are able to set parametrized links, which is basically the same as a get.
Nothing theoretically would prevent you to implement the same logic as the normal jsf forms does with gets, but the fact that there already exist hundreds of controls and no one ever has done it seems to be indication enough that it is not really top priority, because you have static links.
A form get is a case which does not happen too often, and in most cases is neglectable.
A paramterized link can happen often, and is covered by jsf as mentioned before.
|
|
|
Message #197747
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares about HTTP semantics?
JSF has, for more than 3 years, proven unable to achieve enough popularity. JSF has not been out that long as a finalized JSR. The final release was 11 March 2004. Many of us are not keen to use things in production use before this stage.Also, what evidence is there about poor JSF popularity? I have no good way to measure this, except I do see a number of companies investing in JSF components and marketing them, and an increasing number of job offers for JSF developers. I see Oracle donating over a hundred JSF components to open source. I see JSF and JSF-based libraries being highly rated by surveys (OK, these surveys may be questionable, there seems to be a pattern). I guess JSF success stories aren't as exciting as stories as failures!
Add to that myriads of components (Around 40-50 in tomahwak alone) for JSF freely available from the net, besides myfaces several other open source dedicated component projects. Add to that several commercial component packs and at least three implementations of the standard (Sun, IBM, MyFaces)
Add to that several excellent extension frameworks, like Shale, Seam and even Spring has some extension points into JSF and that basically every tool builder already has a working or semi working JSF support in its tools, or plans to add it.
Everything seems to indicate that JSF has gained huge momentum the last year, no sign for a slow adoption, giving the short timeframe JSF now has been finalized in its 1.o incarnation.
|
|
|
Message #197750
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clickable lists with bookmarking
Since there is *so* much confusion about this stuff, here is how you do a clickable list in JSF, where clicking a list item takes you to a bookmarkable page:
In messageList.xhtml:
<h:dataTable value="#{messages}" var="msg">
<h:column>
<h:outputLink value="message.jsf">
<f:param name="messageId" value="#{msg.id}"/>
#{msg.title}
</h:outputLink>
</h:column>
...
</h:dataTable>
In faces-config.xml:
<managed-bean>
<managed-bean-name>viewMessage</managed-bean-name>
<managed-bean-class>ViewMessage</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>messageId</property>
<value>#{param['messageId']}</value>
</managed-property>
</managed-bean>
public class ViewMessage {
private Long messageId;
public void setMessageId(Long messageId) { this.messageId = messageId; }
public Long getMessageId() { return messageId; }
public Message getMessage() {
return getMessageFromTheDatabase(messageId);
}
}
In viewMessage.xhtml:
<div>Title: #{viewMessage.message.title}</div>
<div>Text: #{viewMessage.message.text}</div>
I'll resist the urge to post the Seam version of this code, which is even simpler :-)
|
|
|
Message #197752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clickable lists with bookmarking
If it was up to me, 95% of all JSF pages could just be stateless, uber composite controllers, with working blinkers and pretty debug screens.
|
|
|
Message #197754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
JSF is different from Tapestry in many ways. Tapestry is HTML. JSF is a general server-side GUI system, and has been used to render a range of presentation mechanisms, not just HTML. Actually, this is not the reason at all.
I am not sure I understand what you mean here. I was simply stating that JSF was most likely not a 'reinvention' of concepts introduced by Tapestry. They have different features, and both have been in development for a long time. (JSF was in development for years before the 'Final Draft').
Tapestry could relative easily be modified to support that feature if it was requested. In fact, it is not hard at all to plug in something like that with HiveMind. The matter is just not requested and is not deemed necessary as a result.
Well, there must have been some demand for it, as in the excellent Oracle JSF implementation all components can render HTML, WML and can even display on Telnet. JSF (being a specification, not a product) allows vendors to cater for such niches, whereas as single product may not have the resources to do so.
Tapestry is a great product, but personally I find this particular aspect of JSF very exciting.
|
|
|
Message #197755
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clickable lists with bookmarking
I'll resist the urge to post the Seam version of this code, which is even simpler :-)
Please do it, that might impress some of the EJB critics in here ;-)
|
|
|
Message #197756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
President Bush Not My Choice For The Future
The other day I read a blog where some other idiot stated that George W. Bush was not fit to be President. After checking CNN, however, I found that Mr. Bush was still in office and the government was functioning.
Why is this site discussing blogs from goofs as though they were a) any indication of a technology's value or b) any indication of a technology's market penetration ?
ahh ... I'm just ... WTF ?!? Why should anybody care what good ol' Tim thinks about anything ?!? What ? he's some guy who writes programs ? Oooooo ... Creeping Jesus ! I can barely put up with the insane gibberish from the self-proclaimed experts and salesfarts who spend their careers polluting the atmosphere with their ridiculous lies - why would anyone want to add the uninformed spouting of random programmers to that bad noise ?
Man ... the .NET world is really starting to look good ... at least all the lies and half-truths there are PREDICTABLE and EXPECTED nonsense. aarrggh ...
Nuts.
|
|
|
Message #197757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clickable lists with bookmarking
I'll resist the urge to post the Seam version of this code, which is even simpler :-)
Please don't resist - it would be interesting and useful.
|
|
|
Message #197758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
Steve, you are talking about producers (tool-vendors) and I am talking about consumers (developers). The Tapestry mailing lists have tens of thousands of messages a year, and I can assure you that this feature is definitely not among the requested ones. If it becomes requested, well, it is easy to be added. But like Tapestry's HTML-only templates, this feature can be easily implemented in the other framework if it is required (just as Facelets implements it for JSF).
What I am talking about in my message is that there are fundamental differences between two frameworks that cannot be bridged easily. For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client). This is a direct consequence of the dynamic vs. static approach of building pages that determines most of the core differences between the frameworks.
I guess that in the short run, things like ease of use and general simplicity of the frameworks would make a difference. In the long run fundamental differences like the above would be decisive, as they cannot be resolved. And I believe this topic is about the long run prospects.
|
|
|
Message #197760
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway (in my opinion/experience of course – we did a lot of WAP development).
Dmitry
http://www.servletsuite.com
|
|
|
Message #197762
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry? isn't just HTML
Saying that Tapestry is just HTML isn't accurate. You can use Tapestry to render any kind of markup you want. For example, I've used it successfully to create VoiceXML applications and WML components are included right out of the box. That said, it is true that Tapestry's first order of business is HTML, but it is fully capable of rendering any other markup.
To me JSF's renderkit looks good on paper, but I find it difficult to believe that you can create an effective GUI on a completely different platform simply by changing out the way a component is rendered. Each platform is simply different and may call into question the actual components involved, not just they way they are rendered, in order to get the best user experience.
|
|
|
Message #197763
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Strange
It is a little bizarre to see in the browsers site bar the URL to a view JSP but be presented content from a completely different view JSP. It just seems that some unwritten fundamental rule of web application design has been violated :) Have you tried using <redirect/> tag in the navigation config file?
|
|
|
Message #197764
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Why would anyone use JSF for a bookmarkable site? JSF is more or less specially made for building custom web application, and is a relativily bearable framework for that matter. However it is too specialized to use e.g. for public web development where any other simple framework will do much better.
My complaint with JSF is not in the features it provide, but rather in that it is very hard to extend. Framework is just pretty much monolith and to write a custom component one has to deal with a lot of complex API (and accursed render-kits), which means that it's infeasible to reuse custom application stuff in components.
|
|
|
Message #197766
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
Steve, you are talking about producers (tool-vendors) and I am talking about consumers (developers). The Tapestry mailing lists have tens of thousands of messages a year, and I can assure you that this feature is definitely not among the requested ones. If it becomes requested, well, it is easy to be added.
I am assuming that producers produce based on demand. The point about JSF is that I know such features are already there. Just because it is not in demand for Tapestry does not mean it is not in demand. Tapestry is a highly successful framework that has been known from the start for providing ease of design of HTML pages, and I suppose it will therefore attract primarily HTML designers. From the start JSF has been pitched as a multi-presentation technology.
The thing is, I am not after a product to which things can be potentially added if I request it. I am after features already present and tested and supported. I believe there are a lot of developers in my situation.
For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client).
I can't comment on this, as I don't know enough about this aspect of JSF.
|
|
|
Message #197767
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
What I am talking about in my message is that there are fundamental differences between two frameworks that cannot be bridged easily. For example, a loop with 100 iterations in Tapestry would generate one component that is invoked 100 times. If I am not mistaken, that same loop would generate 100 different components in JSF and then these components would be stored somewhere (in the session or on the client). This is a direct consequence of the dynamic vs. static approach of building pages that determines most of the core differences between the frameworks.
You are kind of correct-- JSF is two phased (faced) such that there is a build phase, then a render phase. The build phase is supported by things like direct Java, JSP, and Facelets whose only job is to construct a component tree. In the case of a build phase based iterator (which is sometimes required), you would end up with 100 components (ex c:forEach).
If it was an interator 'component', then in the render phase, it would act like Tapestry/JSP and evaluate that component 100 times. I will spare the minor, ugly details of niche issues with this in JSF.
The weight difference between JSF and Tapestry is that with Tapestry I believe you have more ability to assert static content, where in JSF, everything is dynamic and we have to do some magic hand waving to manage transient state in the component tree ala Facelets or JSP.
|
|
|
Message #197768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Workarounds for this problem
>You shouldn't be able to trigger events without the component
> tree!
Yes, and in our programming that was one of the biggest problems (not the POST of course). How to deal with the part of the tree in JSF?
Dmitry
http://www.servletsuite.com
|
|
|
Message #197769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway
To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.
|
|
|
Message #197770
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?
In Struts or other action framework a user/browser sends a command to a controller, which decides what to show. In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message.
Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.
|
|
|
Message #197771
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway
The more interesting Renderkits I've seen (WML is not of interest to me), but the XUL (XUL Faces) and some of the *animation* work that Roger Kitain has demonstrated with SVG and JSF.
|
|
|
Message #197772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?In Struts or other action framework a user/browser sends a command to a controller, which decides what to show. In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message. Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.
I really think if JSF had a proper story for stateless operation (GET) within the lifecycle, other than just [render], then I think the framework would get a lot more traction. Gavin has been able to take the JSF foundation and write a framework around it that caters/solves a lot of the use cases people have presented to JSF.
|
|
|
Message #197775
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.
This is spelled out in detail in the following article:
http://blog.exadel.com/?p=19
|
|
|
Message #197776
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry? isn't just HTML
Saying that Tapestry is just HTML isn't accurate. You can use Tapestry to render any kind of markup you want. For example, I've used it successfully to create VoiceXML applications and WML components are included right out of the box. That said, it is true that Tapestry's first order of business is HTML, but it is fully capable of rendering any other markup.
Is it? From the Tapestry website:
"Developing Tapestry applications involves creating HTML templates using plain HTML,"
Even if it is, then as you say, Tapestry's first order of business is HTML. JSF was designed from the start for flexibility. This may not appeal to some developers, but it appeals a lot to me. I like the 'value add' of JSF, where you can get a library of components with alternative renderings available, and where many vendors and groups are working to add even more value, both by designing new components and by extending what existing components can do. I think the potential value (to both developers and vendors) of this increasing 'component market' is not yet widely realised.
To me JSF's renderkit looks good on paper, but I find it difficult to believe that you can create an effective GUI on a completely different platform simply by changing out the way a component is rendered. Each platform is simply different and may call into question the actual components involved, not just they way they are rendered, in order to get the best user experience.
Exactly, but I don't think anyone is saying that a single set of page designs will be effective for a range of presentation technologies. I think the advantage is that you can use the same techniques and the same components for these different technologies; and, I am sure that there can be considerable code re-use both within and behind the presentation layer.
|
|
|
Message #197777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.This is spelled out in detail in the following article:http://blog.exadel.com/?p=19
The problem with that suggestion is that you could bypass action invocation by simply not passing the action parameter.
With JSF 1.2, you can declare phaselistener methods right on the root f:view tag. This allows you to enforce behavior/validation/authorization on a per-view basis.
|
|
|
Message #197780
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
I hope Tim Shadel reads this thread before making his subsequent podcasts, since it was demonstrated clearly in this post that it's entirely possible to do GET parameters cleanly in JSF.
|
|
|
Message #197781
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
It is possible to make JSF behave more like Struts by defining your own view handler that intercepts some of the calls and re-routes them if appropriate.This is spelled out in detail in the following article:http://blog.exadel.com/?p=19 This is a nice hack. I call this a hack because if something is not in the framework and was not suppposed to work that way, but was bent forcefully, it is a hack. Interesting comment left there by Gavin: "I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that. Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed!
Gavin goes on: "AFAICT, the only major reason you would need to 'decide which page to go to', is that your GET request displays different things at different times, for the exact same URL. This is an antipattern. -- this is NOT an antipattern, this is a normal thing for a stateful application, to show how a resource changes over the time, or maybe disappears at all. Stateful resources is the reason browsers have "Refresh" button.
|
|
|
Message #197782
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Why would anyone use JSF for a bookmarkable site? JSF is more or less specially made for building custom web application, and is a relativily bearable framework for that matter. However it is too specialized to use e.g. for public web development where any other simple framework will do much better. Depends, first of all, we have to define what is a ozbkuch web development. If you speak of simple html pages, probably yes, but probably j2ee is the wrong choice at all. But many so called public pages nowadays have similar problems and you need to apply similar techniques like in so called backoffice apps.
If you prefer another framework it is up to you. It really depends on the application.
In so called backoffice applications, real web applications with often complex controls, I would not want to do them without a good component based framework, the demands of the users are simply too high nowadays to feed them with basic html controls anymore.
My complaint with JSF is not in the features it provide, but rather in that it is very hard to extend. Framework is just pretty much monolith and to write a custom component one has to deal with a lot of complex API (and accursed render-kits), which means that it's infeasible to reuse custom application stuff in components.
Well it is in the eye of the beholder. If you talk about the component API, it definitely is too complicated due to the genericness it has, and due to the fact that also hooks into jsp have to be provided for jsp rendering.
It is definitely a no go for reusable application parts, but you can apply different techniques to solve such a problem. Facelets for instance would be the perfect choice here. Easy to apply, easy to reuse for general purpose application component parts building.
As for extending the api is complex. It definitely is not, the api has clear extension points and adding for instance a nav handler, a view handler etc.. is very easy once you have a grasp on the basics of what they are doing.
But you hardly extend the api for application reuse.
;-)
|
|
|
Message #197783
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Gavin rules: nice explanation + code sample. The only problem I have is the starting page of an application, module or wizard. In JSF, browser navigates to a view, not to an action like in Struts. Therefore this view is to be displayed whether it is appropriate or not. There was a security-related complain in this discussion, this is the same thing. What if a view is not appropriate?In Struts or other action framework a user/browser sends a command to a controller, which decides what to show. Well the struts flow is basically a hack against html which
turns the workflow of html and basically most server side rendered uis around 180 degrees.
People who do struts have probably a hard time to adjust to the page action page flow, while probably most other people
who come from other ui systems and have to learn struts have a hard time to grasp the action page action flow.
Anyway what you want to achieve definitely is not a show stopper, there are myriads of ways to solve that.
a) You can use a phase listener
b) You can use a servlet filter
c) You can use a nav handler
d) You can use a page handler
for such an interception
In my last application I opted for a security phase listener just exactly to cover that case.
In JSF a user requests a particular view. This is a huge difference. I think the latter approach may work better if a view contains subviews for different states, so if a user is not authorized it would show "Not authorized" message. Still, command pattern seems simpler and more robust for me: a user sends "show items" command, and controller decides either to show "itemview" or "loginview". Having application deciding what view to show adds security and keeps application consistent: a user simply cannot know which view is appropriate in a particular application state, but application knows.
With a view handler exactly such a thing is doable, a nav handler could also do that stuff, with a phase listener at least a redirect to a different view can be achieved.
|
|
|
Message #197785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway (in my opinion/experience of course – we did a lot of WAP development).Dmitryhttp://www.servletsuite.com It is less that you can switch on the fly, which in my opinion is a theoretical option, it is more that you get a huge code reuse that way, because you work with the same backend code and basically the same tag code just altered to the format needed, if done right.
|
|
|
Message #197786
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
It is not against JSF, but I am just interesting: what is useful in WML rendering? Do you expect to port existing application as is to the mobile? No way to be honest, the most important issue here is a form factor for the mobile (small screen in other words). You will need a different concept (design). So practically you need the special components for the mobile anyway To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.
Explain. For example, with our Struts, Spring, Hibernate series of code, I've successfully pulled validation from the presentation tier. My domain objects are persisted using Hibenate and is injected into both ActionForm and business tier using Spring. In fact, validation is an interface(DataValidator) that is injected into the domain object. I use Struts' validate method to invoke the domain object's validator, but it is complete decoupled from Struts.
I can use the validation even outside the presentation tier. So the reuse is there.
If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implemenation, why use it?
|
|
|
Message #197787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clickable lists with bookmarking
I'll resist the urge to post the Seam version of this code, which is even simpler :-) Please don't resist - it would be interesting and useful.
OK, well, there are a couple of ways to do it. In practice I would probably more likely use an @Factory method, since I kinda like being able to refer to #{message.text} in my view instead of #{viewMessage.message.text}, but I suppose that is a matter of taste. Instead I'll show the thing that is *most* similar to the Plain JSF Way, so you can see how JSF constructs map to the precisely equivalent constructs in Seam.
The two .xhtml pages would be unchanged (see above).
We no longer need a <managed-bean> declaration.
Our Java class simplifies to:
@Name("viewMessage")
public class ViewMessage {
@RequestParameter
private Long messageId;
public Message getMessage() {
return getMessageFromTheDatabase(messageId);
}
}
In my previous post I said "what could be simpler". Well. I was wrong. This is ;-)
|
|
|
Message #197788
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
"I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that.
Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
Stupid example, page that displays current time. Does it displays same time every time? Nope.
Yep, it must. But you would have to be going back in time to repeat the request.
This is the whole point why you ask about something again and again - to see what has changed!
There's a difference between 'what has changed?'(GET) and 'can you induce this change for me? By the way, here is some data which could help you out.'(POST)
|
|
|
Message #197789
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed!
Yes, it is a very silly example! Because "the current time" or "the railway schedule for the A train", or "salary of Tim Shadel" is the "same thing", in my understanding. Things can change over time, but their identity is constant:
http://mydomain.com/currentTime.jsf
http://mydomain.com/railwayShedule.jsf/line=A
http://mydomain.com/employeeDetails.jsf/name=TimShadel
Are all VERY doable in JSF.
"AFAICT, the only major reason you would need to 'decide which page to go to', is that your GET request displays different things at different times, for the exact same URL. This is an antipattern. -- this is NOT an antipattern, this is a normal thing for a stateful application, to show how a resource changes over the time, or maybe disappears at all. Stateful resources is the reason browsers have "Refresh" button.
It is the same page. It is just different data displayed on the page.
You've totally misunderstood my post.
|
|
|
Message #197790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
Right, the funny thing about this thread is that JSF is being criticized for being unRESTful, but the only thing we have really established that JSF can't do (without trivial workarounds) is in fact a thing that is quite contrary to the principles of REST!
The irony :-)
|
|
|
Message #197791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
To me, the attraction is that you can use the same framework to develop such pages, and you can use familiar JSF components, with validation and event handling. You don't need special components. I don't honestly expect to be able to design 'technology portable' web pages, but I do expect to get considerable re-use of code between presentation technologies.Explain. For example, with our Struts, Spring, Hibernate series of code, I've successfully pulled validation from the presentation tier. My domain objects are persisted using Hibenate and is injected into both ActionForm and business tier using Spring. In fact, validation is an interface(DataValidator) that is injected into the domain object. I use Struts' validate method to invoke the domain object's validator, but it is complete decoupled from Struts.I can use the validation even outside the presentation tier. So the reuse is there.If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implemenation, why use it?Vendors' pressure (they don't want to dump money to create different tools for different frameworks, they want one standard)? Tool support? Viewstate? Validation/conversion? Components, after all? For the last one I have an answer: it is possible to create components with pure JSP as well.
---
Michael Jouravlev
JSP ControlsBuild independent page components with JSP
|
|
|
Message #197792
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tim Shadel says JSF isn't their choice for the future
"I think the reason why JSF doesn’t let an action handler determine the view to use on a GET request is that this is an unnatural thing to do given the semantics of GET! POST, PUT, DELETE can “decide” things," -- I agree with that part of the sentence. "but GET should just display something; the same thing every time" -- I totally don't agree with that. Please read the HTTP RFC document. If you still don't agree with what Gavin said, you can either stop your web development, or change the protocol.
9.3 GET: "The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI". ... "The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client."
I think you confuse response caching and history lists. In the latter case response should be identical to a prior, this is the point that Opera guys make when they are being asked why Opera does not reload a page when a user goes back and a page is marked as "no-cache, no-store". See section 13.13.
Maybe you need to read HTTP spec yourself?Stupid example, page that displays current time. Does it displays same time every time? Nope. Or railway schedule, it can change over time. Or order status, it can be removed after goods are delivered or after certain period of time. Or employee data, it surely changes. GET means "give me info about something", it does not mean "give me info about something and make sure that it is the same as yesterday and it will be the same tomorrow". This is the whole point why you ask about something again and again - to see what has changed! Yes, it is a very silly example! Because "the current time" or "the railway schedule for the A train", or "salary of Tim Shadel" is the "same thing", in my understanding. Things can change over time, but their identity is constant:http://mydomain.com/currentTime.jsf http://mydomain.com/railwayShedule.jsf/line=A http://mydomain.com/employeeDetails.jsf/name=TimShadelAre all VERY doable in JSF.
Now I see what you mean by the "same thing": the identity. Of course, I agree with this definition ;-)
|
|
|
Message #197794
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry?
If JSF doesn't offer the ability to easily move from say PDF to HTML to WML by just changing implementation, why use it?
Because it does offer this. You can do this without changing implementa | |
