I'm coming into Java world from MS and ASP.NET and looking for the similar to ASP.NET component-based HTML framework in Java. After reviewing tons of links in internet it looks like JSF2 (with facelets) is best match (is this true by the way? or there are other better choices?).
The problem I'm encountering during evaluation right now is correct usage of JSF's view state. My final usage scenario would be a clustered WEB server and i'm NOT going to have any session/server-stored objects and i'm NOT going to use network bandwidth for dummy view state (see another guy's somewhat related problem here JSF Tuning).
I took some JSF2 tutorial and after setting javax.faces.STATE_SAVING_METHOD = client got ViewState generated into HTML of 440 chars (omygod, page contains just 1 dummy text input and 1 submit button). In "POST on submit" I do need only text from text input (10 chars) and not that dummy view state (440 chars).
So the question is - Is it possible to disable view state in JSF2?
Relevant links:
Use-case in ASP.NET - "Disable View State for a Page":
http://www.ironspeed.com/articles/Disable%20View%20State%20for%20a%20Page/Article.aspx
Not helpful answer on stackoverflow:
How to reduce javax.faces.ViewState in JSF
Update: Relevant links (from comments below):
JSF 2.0 partial state saving does not seem to work
"Stateless JSF": http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead
JSF is a component based framework which is heavily stateful - so you need the state somewhere, either sent to the client over the wire and posted in again, or on the server side. So AFAIK the answer is No, you cannot disable the View state. But you can minimize it - however some state will always need storing. This link is relevant.
If you're looking for a Java web framework which is not so stateful - then maybe look at some Action based framework like Struts or Stripes, so you can work in Request scope and not need a component tree present (or rebuilt) on a postback. The Play framework has been gaining good press - which is specifically designed to target RESTful architectures. I do not have experience of this myself, but you may want to investigate it. Taken from the Play website:
Simple stateless MVC architecture
You’ve got a database on one side and a web browser on the other. Why
should you have a state in between?
Stateful and component based Java Web frameworks make it easy to
automatically save page state, but that brings a lot of other
problems: what happens if the user opens a second window? What if the
user hits the browser back button?
Since Mojarra 2.1.19 and Mojarra 2.2.0-m10 it's possible to disable the state saving on a per-view basis by setting the transient attribute of <f:view> to true.
<f:view transient="true">
...
<h:form>
...
</h:form>
...
</f:view>
See also:
JSF is going stateless
What is the usefulness of statelessness in JSF?
Related
I created few threads in a web application and I have a datatable component in JSF page.
I would like to update the table automatically to show the current status of thread. Is there any prebuild component I can use in this scenario?
I created few threads in a web application
I wholeheartedly hope that you did it the right way and thus it don't end up in an epic disaster.
I would like to update the table automatically to show the current status of thread. Is there any prebuild component I can use in this scenario?
You're basically looking for a technique called "polling" or "pushing". The basic concept of polling is to use JavaScript's setInterval() or setTimeout() to fire a (ajax) HTTP request to the server at intervals and let it process the results accordingly. The basic concept of pushing is to open a persistent HTTP connection and have the server send small messages over it, this can be done with among others WebSocket in JavaScript and JSR356 API in Java EE 7.
The standard JSF implementation doesn't offer any ready-to-use poll or push component out the box. For the upcoming JSF 2.3, a new <f:websocket> tag is currently in progress (see also issue 1396).
Your best bet would be a hidden form with a hidden command link/button with <f:ajax> and then invoke it by setInterval(). Component libraries like PrimeFaces however offer ready-to-use components out the box, see also <p:poll> showcase and <p:push> showcase for some concrete examples. JSF utility library OmniFaces has in its <o:commandScript> showcase a poll example and in <o:socket> showcase several push examples (the new standard JSF <f:websocket> will be largely based on <o:socket>).
See also:
How do I ajax-update a component at an interval of 1 second?
Real time updates from database using JSF/Java EE
How can server push asynchronous changes to a HTML page created by JSF?
I'm exploring the JSF 2.2 Faces Flow feature but I'm still not sure what are the advantages of defining a flow using Faces Flow instead of using the normal navigation system (calling facelets in links or buttons)?
Only use it if you want to use a #FlowScoped bean on a given set of views. In other words, only use it if you want a managed bean which should live as long as you're navigating through the specified collection of views registered in the flow configuration file.
There are indeed very few real world use cases for this. They all boil down to a multi-step wizard of which each step is bookmarkable. Previously, before the introduction of the flow scope, one would use conditionally rendered includes for this, but they are in turn not individually bookmarkable, because the URL stays the same all the time.
See also:
What is new in JSF 2.2? - Faces Flow
Java EE 7 tutorial - Using Faces Flows
How to navigate in JSF? How to make URL reflect current page (and not previous one)
Faces flow and navigation are different.
Face flow like business flow in the frond end site, much like wizard.
We are using JavaServer Faces 2.2 (Mojarra 2.2.1) in our project. I noticed something odd. On a page called reporting.xhtml where I use f:metadata with the new f:viewAction my browser, Safari in this case, shows the following query string:
reporting.jsf?jftfdi=&jffi=reporting%3Ffaces-redirect%3Dtrue
What wizardry is this? What are the parameters jftfdi and jiffi doing? What is their purpose?
It's part of the new JSF 2.2 feature as described by spec issue 949. Basically, it enables JSF to identify the client window. It's basically the same as cid in CDI's #ConversationScoped and windowId in CODI's #ViewScoped/#ViewAccessScoped. This client window ID is in turn used by among others the new JSF 2.2 #FlowScoped scope as described by spec issue 730.
The "What's new in JSF 2.2?" article of my fellow Arjan Tijms explains the need pretty clearly:
LifeCycle
Identify client windows via a Window Id
Arguably one of the biggest problems that has been plaguing web application development since its inception is the inability to distinguish requests originating from different windows of a single browser. Not only has an actual solution been long overdue, it has taken a long time to realize this even was a problem.
The root of the problem, as always, is that the HTTP protocol is inherently stateless while applications in general are not. There is the concept of a cookie though, which is overwhelmingly the mechanism used to distinguish requests from different users and to implement things like a session scope where on its turn the bulk of login mechanisms are based on.
While a cookie does work for this, it’s global per browser and domain. If a user opens multiple tabs or windows for the same domain then requests from those will all send the same cookie to the server. Logging in as a different user in a different window for the same website is thus not normally possible, and having workflows (involving post-backs, navigation) in different windows can also be troublesome because of this.
In JSF there are various solutions that are somehow related to this. The view scope effectively implements a session per window as long as the user stays on the same page and does only post-backs. The Flash is used for transferring data between different pages (presumably within the same window) when navigation is done via Redirect/GET. There’s a wide variety of scopes implemented by third parties that do something similar.
All of these have some implicit notion or assumption of the concept of a ‘client window’, but there is no explicit API for this.
JSF 2.2 will introduce support for two different aspects of this:
Identification of an individual window: the Client Window Id
API and life-cyle awareness of the window concept
Apparently you've configured your application as such.
See also:
What's new in JSF 2.2? - Lifecycle - Identify client windows via window Id
What's new in JSF 2.2? - Navigation - Faces Flow
I'm trying to use ace:fileEntry to upload a picture, as I read this component requires a submit from h:commandButton in order to start downloading. My problem is that when I switched my ice:commandButton with h:, my managed bean (which is in Conversation Scope) gets created again (#PostConstruct called) and the method in h:commandButton and also the fileEntryListener aren't called anymore.
And as another problem that might be causing this is that when I first enter my page the managed bean gets created and I call conversation begin, but when I do a second request (from a commandLink) the managed bean is created again, and a new conversation is started, after that you can play how long do you want the managed bean doesn't get created again.
Back to my initial question, if I have ice:commandButton the managed bean ins't created again, if it's with h: it gets created again.
And to add a little bit more fun in it, if I remove the rendered attribute (which resolves to true) from ace:fileEntry the fileEntryListener is called, but the action from h:commandButton isn't called no matter what.
I tried to add explicit ids to the components, tried to change ice:form with h:form .. nothing. Please Help.
Ps: why ICEfaces 2 can't work with all ice components, why does it requires h:commandButton, instead of ice:commandButton, why the new JSF 2.0 stuff with f:selectItems backed by a regular list isn't working with ice:selectOneMenu, works just with h:selectOneMenu ? What's up with ICEfaces ? And why CDI doesn't work as expected, with Seam 2 also I had problems with conversations called twice .. ps2: if I don't navigate to another view ?cid=1 isn't present in the URL.
Now, with ace:fileEntry and h:commandButton, the reason why the ice:commandButton can not be used is because that is an AJAX component, and browsers will not upload files in an AJAX submit. Even with HTML5 it is not automatic, and new File and XmlHttpRequest APIs must be used. In an HTML4 browser, only a full page, full form, submit will upload the file contents, and only h:commandButton operates that way. For more details, you can see this explained near the top of the page at:
http://wiki.icefaces.org/display/ICE/FileEntry
With our ice: components, which are extended variants of the h: components, such as ice:selectOneMenu, they are lacking some new JSF 2 features because we have been focusing on our newer Advanced Component Environment, due to customer demand for rich client-side components. As well, the focus was on maintaining backwards compatibility with the ice: components, to ease customer migration from ICEfaces 1.8.x to ICEfaces 2.x, and less so to be altering those components' behaviours. But we are still actively maintaining and improving the ice: components, and will be adding the new features soon. Feel free to create any enhancement requests in our Jira system, and to vote on any existing entries, as this does guide our development priorities.
http://jira.icefaces.org/
Mark Collette
I'm Mark Collette from the ICEfaces component team, and hopefully I can answer some of your questions.
Most of your issues seem more related to CDI integration than problems with the components themselves. I know that the symptoms change depending on which component you use, but I think that's because the ice: components use AJAX and the h: components do not. Many times integration issues with other frameworks are more observable in AJAX interactions than in full page GET/POST interactions. So your issues may be due to either our CDI integration, or your application's configuration. So please review our documentation on using ICEfaces with CDI, and if you you still experience any issues, I recommend posting the details to our forums.
http://wiki.icefaces.org/display/ICE/Using+ICEfaces+with+CDI
http://www.icefaces.org/JForum/forums/list.page
[Sorry, but this forum is not letting me post more than 2 links, so I'll split the rest of my message into another post, and hopefully that will work]
Mark Collette
What do people think is the best JSF framework or library for a saving state longer than request scope (but w/o using session scope) that is backbutton/new window safe -- i.e. you have a "wizard"/multi-page form.
For example, MyFaces has the 'SaveState' tag that allows you to maintain state across pages by saving state in the view's component tree. Any comments on SaveState (pros/cons) or suggestions for any better framework or library for this capability?
The t:saveState works perfectly. It's only a bit 'low level' and not tied to a particular bean. There are two other libraries/frameworks which comes to mind which provides control over conversation scope at higher level (e.g. bean-specific tags/annotations):
Apache MyFaces Orchestra (uses tags)
JBoss Seam (uses annotations)
Update: JSF2.0 has added a new scope which achieves a conversation-like state, the #ViewScope. Very useful if you can reuse the same view for subsequent actions.
i think Spring Web Flow is a good solution. you can define your flow as XML and it can integrate with JSF, Struts, Spring MVC, ZK,...
http://www.springsource.org/webflow