is it possible (and if so how) to route the MODEL exception messages to be presented on the JSF page and NOT in a popup?
scenario:
JSF page contains master-detail tables
when a user clicks on a row of the master table, there are some operations (Iterator+ExceuteWithParams) executed in the detailImpl.java (by prepareRowSetForQuery(ViewRowSetImpl vrs).
some of those operations can return exceptions from the DB. we don't want those exception messages to be presented as popups, but instead to be shown inside the JSF page in a certain place that will be used for those messages (Ex. af:outputText). the component needs to be updated with the new error every time it was thrown from the model
how it can be done?
examples please
try experimenting with 'af:messages' component.
Related
In my Windows Phone App there's a simple hierarchical model consisting of a class containing a collection of other domain objects.
In my xaml i have declared an ItemsContainer control that renders the items in the above mentioned collection as simple rectangles.
Now, at the VM level i have a structure that resembles my model with a parent VM having a collection of children VMs. Each child-VM encapsulates its own model.
Whenever the user taps the view bound to a child-VM a method of the parent-model object should be invoked taking the relevant child-model as parameter. This will in turn change some internal state that will be reflected (possibly) on all the child-views (not just the tapped one).
SO... given that i'm using the MVVM Light framework my current implementation is as follows:
Child-VM exposes a command
The command Execute method will use the messenger to notify the parent-VM of the tap event. The message (GenericMessage class) content will be the domain object encapsulated by the VM
The parent-VM executes the method of the parent-model using the message content as parameter
If the operation succeeds the parent-VM sends a new message to inform child-VMs of this fact. Once again the message content is the model object used as parameter in the method that was just invoked
Child-VMs raise a couple of PropertyChanged events that, finally, will update the bound views
It works but i fill it's a bit cumbersome. The thing that bugs me the most is the fact that when a child-view is tapped the associated VM will broadcast its encapsulated model object. Do you feel that there would be a better way of implementing such a system?
Thanks in advance for your precious help
Could you not just put the command on the parent viewmodel and pass the child viewmodel as the command parameter?
The parent view model can then just call methods on the child viewmodels to update them. I'm not sure I see the need for all these messages?
I have an Android app which uses a SupportActionBar that contains a bunch of tabs. These tabs each have a fragment that in turn are connected to a ViewModel in my core project. This works great and when i start the app they are all initialized right away and setup correctly.
What i would like to do is to call on a method on one of these ViewModels from my main activity that contains all the tabs and fragments.
I read in another post that in WP you could cast the DataContext to the ViewModel but that might not work in Android. I haven't been able to do this, maybe because my DataContext is not the currently displayed ViewModel but the MainViewModel connected to my main activity. Or maybe it's not supposed to be done that way, i'm not sure.
I'm trying to do this:
var test = (MessagesViewModel)this.DataContext;
test.GetViewDataFromApi();
To update the data in the view when i press the tab. I can't use the Init function for this for example since the ViewModel isn't recreated everytime i show the view.
Are you trying to update some data in the tab's fragment when tab is selected?
If that's the case, one way to do it is to
1) handle the tab selection event to get the current tab(maybe using TabListener),
2) get the fragment (MvxFagment) in the selected tab
3) get the (IMvxViewModel) view-model from the fragment
4) call the method you need to update data on the view-model
I assume you are using a MvxFragment (https://github.com/MvvmCross/MvvmCross/blob/v3.1/Cirrious/Cirrious.MvvmCross.Droid.Fragging/Fragments/MvxFragment.cs?source=cc) so you can access the view-model from the MvxFragment's ViewModel property.
I'm using the code found here for Ajax ordered/pagination support for a Seam EntityQuery. The code itself is working great, and I am able to sort my data with no problem by various parameters. The entity itself is not a SQL table, but rather a SQL view mapped to a JPA (Hibernate) Entity. That, too, seems to be working without issue, so long as I stick to SELECT statements and not try to perform an INSERT or UPDATE. My backend DB is PostgreSQL 8.4, and I haven't implemented any conditional TRIGGERs to allow for VIEW update support.
My problem has to do when I go from one page of results to another using the EntityQuery.next() or EntityQuery.previous() methods. It appears the entire page request is wrapped in a transaction, and when I click my next button it attempts to perform an UPDATE on my Entity object. I've overridden the next() method in my EntityQuery and that operation goes through successfully. But, immediately after it finishes and right before the view is rendered the attempted UPDATE occurs. Since my Entity object can't be updated on the backend DB (since it's a VIEW) I get an Exception thrown.
Is there any way to prevent a transaction from being opened when using this EntityQuery? I've tried annotating my Entity object with #ReadOnly. That didn't work. I've tried adding #Transactional(NEVER) to my EntityQuery. That didn't work. Any other ideas?
Try changing to session scope on your component. That way seam will load the object from memory instead of hitting the database.
#Scope(ScopeType.SESSION)
I’m struggling fully understanding when/how exceptions are thrown in JSF 2.0. I’ve looked for a solution longer than I care to admit. Ultimately, the goal I want to achieve is “handle” an unhandled exceptions. When an exception is thrown, I want to be able to capture information of interest about the exception, and email that to the appropriate site administrators. I’m forcing an error by throwing a new FacesException() in the constructor of one of my backing beans. I had this working great in JSF 1.1 using MyFaces implementation. I was able to get this working by wrapping the Default Lifecycle and simply overriding the execute() and render() methods. I followed this awesome post by Hanspeter to get that working:
"http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/#comment-103"
I am now undergoing a site upgrade to JSF 2.0 using Mojarra’s. And things work great still as long as the exception is thrown/caught in the execute() method, however; the moment I enter the render(), the HttpServletResponse.isCommitted() equals true, and the phase is PhaseId RENDER_RESPONSE which of course means I can’t perform a redirect or forward. I don’t understand what has changed between JSF 1.1 and 2.0 in regards to when/how the response is committed. As I indicated, I had this working perfectly in the 1.1 framework.
After much searching I found that JSF 2.0 provides a great option for exception handling via a Custom ExceptionHandler. I followed Ed Burns’ blog, Dealing Gracefully with ViewExpiredException in JSF2:
"http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2"
As Ed indicates there is always the web.xml way by defining the tag and what type of exception/server error code and to what page one wants sent to for the error. This approach works great as long as I’m catching 404 errors. One interesting thing to note about that however, is if I force a 404 error by typing a non-exsitant URL like /myApp/9er the error handler works great, but as soon as I add “.xhtml” extension (i.e. /myApp/9er.xhtml) then the web.xml definition doesn’t handle it.
One thing I noticed Ed was doing that I hadn’t tried was instead of trying to do a HttpServletRespone.sendRedirect(), he is utilizing the Navigationhandler.handleNavigation() to forward the user to the custom error page. Unfortunately, this method didn’t do anything different than what Faclets does with the error by default. Along with that of course, I was unable to do HttpServletResponse.sendRedirect() due to the same problems as mentioned above; response.isCommitted() equals true.
I know this post is getting long so I will make a quick note about trying to use a PhaseListener for the same purposes. I used the following posts as a guide with this route still being unsuccessful:
"http://ovaraksin.blogspot.com/2010/10/global-handling-of-all-unchecked.html" "http://ovaraksin.blogspot.com/2010/10/jsf-ajax-redirect-after-session-timeout.html"
All and all I have the same issues as already mentioned. When this exception is thrown, the response is already in the committed phase, and I’m unable to redirect/forward the user to a standard error page.
I apologize for such a long post, I’m just trying to give as much information as possible to help eliminate ambiguity. Anyone have any ideas/thoughts to a work around, and I’m curious what might be different between JSF 1.1 and 2.0 that would cause the response to be committed as soon as I enter the render() phase of the Lifecycle.
Thanks a ton for any help with this!!!
So this question is actually not just about a custom exception handler (for which JSF 2 has the powerful ExceptionHandlerFactory mechanism), but more about showing the user a custom error page when the response has already been committed.
One universal way to always be able to redirect the user even if the last bit has already been written to the response is using a HttpServletResponse wrapper that buffers headers and content being written to it.
This does have the adverse effect that the user doesn't see the page being build up gradually.
Maybe you can use this technique to only capture the very early response commit that JSF 2.0 seems to do. As soon as render response starts, you emit the headers you buffered till so far and write out the response content directly.
This way you might still be able to redirect the user to a custom error page if the exception occurs before render response.
I have successfully implemented a filter using response wrapper as described above which avoids the response being commited and allows redirection to a custom page even on an exception in the middle of rendering the page.
The response wrapper sets up its own internal PrintWriter on a StringWriter, which is returned by the getWriter method so that the faces output is buffered. In the happy path, the filter subsequently writes the internal StringWriter contents to the actual response. On an exception, the filter redirects to an error jsp which writes to the (as yet uncommitted) response.
For me, the key to avoiding the response getting committed was to intercept the flushBuffer() method (from ServletResponse, not HttpServletResponse), and avoid calling super.flushBuffer(). I suspect that depending on circumstances and as noted above, it might also be necessary to also override some of the other methods, eg the ones that set headers.
I have a tree control in my GUI (with naturally lots of GUI/platform specific functions to handle the nodes).
I have a data model with its own complex set of nodes, children, properties etc..
I want the tree to display a representation of the model, be able to send messages to the nodes inside the model and be told to redraw itself when the model changes.
But I don't want the GUI code to need to know the details of the model's data types and I don't want to pollute the model by linking it to the GUI classes.
I can't get my head around how the controller is supposed to do this and what functions it should provide?
(this is in C++ but that shouldn't matter)
GUI "controls" don't quite fit neatly into a model-view-controller pattern because they typically have their own internal model rather than accepting a reference to one. If the control is structured that way, you'll need an adapter class that "data-binds" the control's internal model to the underlying data model.
This can accomplish something similar to what model-view-controller would, except that the adapter class plays the role both of a view hookup component (updating the GUI from the data model) and a controller (interpreting GUI events into model actions).
Qt provides a group of classes for model-view programming. You can hook a tree view to a filesystem model, for example, and neither directly know anything about each other (except a pointer to the model in the view).
Your requirements are:
Tree displays representation of model
Nodes in tree can send messages to nodes inside model
Tree redraws itself based on model changes
I don't know exactly what kind of data you're working with here, but a hierarchical model is a fairly simple thing. I'll take it as a given you know how to iterate hierarchical data and populate a tree view.
Your controller should have member function(s) for sending messages to the model. The parameters should be a model element and the message you want to send. This way, the UI is completely unaware of how the message gets to the element, but can get the messages through.
The last requirement is more tricky, and depends on a few things (e.g., the lifetime of the controller, application architecture, etc.) I'm going to assume the controller lives as long as the tree view does. If that's the case, then your controller should provide a way to set a callback on model changes. Then, when the controller changes the model, it can callback to the UI without being aware of the UI.
i think your troubles start with an unfortunate choice of words. the 'control' thingies doesn't have anything to do with the 'controller' in MVC. that's why some GUI libraries use other names (widgets is a common one).
your 'tree control' is the view, not the controller. it should be tied to the GUI, both for display, and to get GUI events and turn them into 'tree events'.
the controller gets those 'tree events' and does the necessary modifications to the model. that's where you couple the 'action' with the 'response'.
First Solution: You can implement a "Subject observer" pattern between model and view, with model as the subject and view as the observer. Whenever there is a change in the state of model, it can fire a event to all the observers those are registered, they can update themselves.
Second Solution: Introduce a controller, which registers with model as observer. Upon receiving a event for update from Model, it can update the view. Even you can decouple view from controller using one more subject observer pattern between controller and view
Third Solution: Use MVP pattern. Model view Presenter. This pattern used whenever there is no much computation in controller i.e., job of the controller is just to update its corresponding view. Here controller becomes Presenter.
You need a controller that sits outside the display widget but has the state of the tree (in MFc there are CTreeView/CTreeCtrl classes - there is a similiar separation in Qt) the tree controller handles all the data storage and calls redraws on the tree widget.
Changes in the tree widget get sent to the tree controller - so this controller needs to know about the gui functions.
The model will need set/get functions for all the relevant parameters for the nodes. But these can return simple types so aren't dependent on the gui.
Updating the view form the model requires sending a message, if you don't want the model to know about your gui messaging the best you can do is register a callback function (a void pointer to a function) from the tree controller - and call this to do an update.
This update function can then query the model for the changes.