When a user clicks a button on JSF, a managed bean receives the input value from front end. To process the request and respond, when should or shouldn't I implement a CDI event? For instance, to print back "Hello World" to html page after a user clicks a button on a front end JSF page, I can implement a CDI Event using event-observer model, or I can do the same thing in many other ways.
My question is, what are appropriate scenarios to implement a request-process operation as a CDI event? Thanks.
Usually you want to use events when a request from user will affect multiple parts of application. Let's say user changed some settings it his profile and they are multiple components affected by this change so you can fire up an single event and all these components will be able to handle the configuration change.
Another argument for using events is to decouple your components so there are less dependencies in your application.
So for your example, events are probably overkill for such simple operation as printing Hello world.
Related
I have just discovered how awesome XMPP is and I am experimenting with developing multiplayer games as XMPP components (XEP-0114).
However, I am having trouble with indicating presence for the component. Is it true, that the component will need to respond to <presence> stanzas itself?
Sure it can do that, but not if it is down for maintenance. Also, who does the component notify when it is back up? It could of course register all interested users in a database, but if it is down for five minutes, then that list surely will have changed. Users that were not previously interested will be now, and users who were interested won't be any more.
Also, if it crashes (could happen), it cannot send out 'unavailable' presence indications.
Can't this work somehow be offloaded to the server?
When your component receives <presence type='probe'/>, it should reply with your component's current presence.
When your component receives <presence type='subscribe'/>, it should save the from address in a some sort of storage mechanism, then reply with <presence type='subscribed'/>.
When your component comes online, it should send presence to each of the subscribers saved in step 2.
Always make sure to put both a to address and a from address on all stanzas sent by your component. If you are used to writing clients, you're likely to forget that in step 3.
I'm getting BusyConversationException while navigating through pages in my jsf project. This mostly happens if the user tries to navigate to another page during an ajax call. This also happens when the user clicks on a link right after clicking on another link without waiting for loading of the page.
For example if the user clicks on more than one link which are generated through a code similar to below one we definitely get this exception. Another example is, lets say the user enter a query on a text field, and our application make an ajax call for searching this query. During that query if the user click on some button to navigate to another page BusyConversationException occurs too.
<h:commandLink value="#{theProfile.profileName}"
title="#{theProfile.profileName}"
action="#{profileBean.aProfileSelected}">
<f:setPropertyActionListener target="#{currentProfileWebBean.theProfile}" value="#{theProfile}"/>
</h:commandLink>
I can catch this type of exception in an ExceptionHandler class which extends ExceptionHandlerWrapper class but I can't save my current state and the best I can do for this case is to redirect to main page when this exception occurs.
Is there any solution for avoiding this? Thanks in advance for answers and comments.
As mentioned in the other answers, this happens if an ajax request is still being processed or if an ajax event is triggered prior to the actual click on the submitting commandLink or commandButton (for instance by a change event on an input field).
Therfore it is not possible to avoid BusyConversationExceptions with onclick="preventEventPropagation(event)";, since the AJAX events are not triggered via propagation.
The issue can easily be avoided by listening for running ajax requests and blocking submits until the pending ajax events have been completed.
The issue and solution are explained in more detail in this blog post JSF2 AJAX/Submit conversation issue.
i found this,
Indicates that the container has rejected a request because a concurrent request is associated with the same conversation context.
The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type BusyConversationException from the restore view phase of the JSF lifecycle.
refer here
I've been seeing this occasionally too. I'm starting to think it's a good idea to put some effort into serializing access to conversations:
Avoid propagating the conversation ID (cid) when you don't need that conversation instance for the target view. Specifically, unrelated navigation links/buttons should suppress the cid parameter (haven't thought about exactly how to do that)
When starting a request that uses an active conversation, disable other UI elements that propagate the conversation and could therefore cause concurrent access. The PrimeFaces or (even better) PrimeFaces Extensions blockUI components work well as a translucent overlay, along with a PrimeFaces p:ajaxStatus to show the busy status.
Begin conversations as late as possible. This will minimize the cases where a long-running conversation would be propagated.
I don't think that any of this is a complete solution, though. As soon as the cid ends up in the location bar (which happens when you do a non-ajax post back of a form when a conversation is active), you potentially lose control over the timing of access to that conversation due to multiple tabs/windows, bookmarks, etc.
I also faced the same problem, when I used to click the .
I have read in one of the book, busyConevrsation happens with that event two actions are happening, so they said use : onclick="preventEventPropagation(event)"; in commandLink to prevent the event propagation for that click. So I have used the same and it's working for me.
So now am not getting the BusyConversationException :)
I'm trying to add some features to my webapp, something like a "live user-to-user" chat (like Facebook's one) and a realtime notifications system.
Let's consider this scenario :
We've got two users, A and B.
A sends a message to B.
If the chat window between B and A is opened on B's browser, we update it, showing the new message on B's browser.
If the windows's not opened, we need to show a notification or something on B's browser.
So, having a PrimeFaces Dialog as the chat window and a PrimeFaces NotificationBar to show notifications, how can I do that?
I can't use PrimeFaces' push as they don't work with Glassfish.
I've found out about ICEPush, that seems to be a nice way to do this, but the thing about "Rendering groups" stopped me from trying it.
How can I update just a SINGLE client if ICEPush talks about groups?
Should I create a new group for each client?
Something like :
B has a "BwithA" group that is updated when A sends a message to B and the chat is opened, and a "notificationsB" group that is updated when the chat windows is closed?
I can't find out how to do that because, even using groups this way, is A that has to tell B that he needs to update, and A doesn't know if B has to update the dialog or the notificationBar !
I hope that the question is clear, because it's not easy to explain it|
Thanks in advance :)
I don't know how a professional Java programmer would solve your problem, but when I wanted to create a chat, I used standard Primefaces Remote Command component and call-back parameters to create chat and send new messages to user's from the server.
There is a p:remoteCommand component on web-page. The purpose of the component is to get the latest messages from a particular user when action listener is invoked. New messages are passed from the server to javascript function (handler of oncomplete event of the component) via "call-back parameters". The function then checks if there are any messages and appends them to the chat box.
For more information, see How to create JSF chat with AJAX
UPD: the solution above is outdated. Now I would use JAX-RS web-services or web sockets to implement chat. There is also a commercial solutions for real-time data streaming: PubNub, Pusher, etc.
In our current prototype most the standard HTML controls are replaced by an applet, most important the form submission is triggered by the applet.
Is there a way to call an associated action on the server side much the same way as with
<h:commandButton action="#{ctrl.doit}"/>?
This article Applet and JSF Integration - example had the same question but not a suitable answer. The applet is a drop in replacement for a form from the viewpoint of the server. It fills dedicated (hidden) fields and submits - no direct communication to a server.
EDIT
So far, i understand there are these integration possibilities:
add a (hidden) UICommand and trigger it via JavaScript
Implement a UICommand of your own. As far as i understand, i'd define a hidden parameter for marking the applet as the form submit control, in the request processing cycle the UICommand implementation will find out and trigger the action. Maybe one should implement a virtual control (comparable to f:viewParam) as an endpoint for MethodExpressions.
Attach a listener, either to a (random) control or a more general event listener and do your stuff here. In this case, how is navigation done?
This is not possible without having a physical JSF view in the very same page which has the applet embedded. So, you should really at least have a <h:form> with a <h:commandButton> in the same page, if necessary hidden by CSS display: none;. This is simply because JSF needs to have a view state of that form in the server side, among others to prevent CSRF-like attacks. If having a physical <h:form> in the page is not a problem for you (which seems to be true in your particular case), then you can just let Applet fill the fields (if any) and click the button of the form using Applet-JavaScript communication.
Other than that, a simple servlet or a real webservice API like JAX-RS/JAX-WS is really the best way. JSF is a component based MVC framework and not a webservice framework. That's what my answer in that linked question is trying to make clear: use the right tool for the job.
I am writing a simple enough program using JSF, and I need some advice about how to go about it. I have a jsp which takes a unique ID and has to find out if the ID exists in 3 different databases. If it does it should display a message telling user, where it exists, otherwise it should give the user option to add the ID to a particular database.
I have the jsp page which has a text field for the input ID and I have a button called "Submit" which should trigger the process of querying the db to see where the ID exists. My question is, how to structure this project, in terms of front end, middle teir and db layer.
I have a JSP page, when the user clicks the Submit button, I have a listener in the managed bean which gets executed. I have also read up that the listeners can either be a managed bean or a separate class. Should I have a separate class which is the listener? If so, should it be a Servlet mapping in the web.xml file, so all request get forwarded to this class. Should there then be a separate DAO class where the actual query
gets executed. We are using hibernate as well.
I would jsut like to hear people comments about how many classes there should be and how a particular ID Check will flow through the program from JSP->Servlet(?)-> DAO and then back to the same jsp. There is only JSP , there will be no other navigation pages.
Any direction will be much appreciated.
I have used Spring in the past, and this would be a breeze fore me with Spring, using the Controllers to delegate the requests to the appropriate service, and then the service would call the DAO class. But here we are using JSF and it has to be a JSF web page. I have not used JSF before so I am unsure about the different components needed. I have the front end jsp and a DAO class with the actual query, just wondering about the middle tier, with business logic. How does the front end request after clicking the Submit button get to the middle tier, what wiring is required? Is it in the web.xml?
I would suggest you take a good long look at Spring framework. Here's a Spring MVC tutorial to get you started.