Simple, componentTest doesn't set up a page context - somewhere you are trying to access the page context.
The odd thing is that I am really not accessing the page context. In fact, I am not doing anything. The line I showed above where I call setValue is the only line in my test! Yet that is where the ELException arises.
By the way, nice to know someone else is working today.
Let's see searchAction.
I got bored doing family stuff ;)
Problem solved. I had a property annotated with @DataModel(scope=ScopeType.PAGE). Once I remove that, it works.
This does beg some questions though. I am trying to figure out the right context for a very common scenario:
1) User enters search criteria on a page and presses a button
2) Widget search results are presented on the same page below the form
3) User clicks on the widget link in the table and gets to see all the details about it
4) If user is authorized, user then may edit the information about the chosen widget OR user may go back to see the search results again to select another widget OR user may just read about the widget and hyperlink out to some other part of the site
I am working with JavaBeans, and the collection is annotated with @DataModel and the particular widget with @DataModelSelection.
My questions are these:
1) Is the default scope of EVENT sufficient for this? I ask because I am a bit unclear on what EVENT actually means. Even though I had PAGE before to cause that error I mentioned, CONVERSATION seems like it might be the best choice when I think about it. But if this is so, how would the conversation end in the case where the user just reads the widget details (no editing) and just decides to click a hyperlink to venture off to some unrelated area?
2) What is the best way to simulate the above paths in a FacesRequest test? Can I simply write a single method and call the run() method on the different requests one after another?
Thanks again for the insight.
And I can understand getting bored doing family stuff.
1) Page scope is appropriate here, assuming that the edit panel is on the same view id as the search. A long running conversation would be as well, and would be the standard choice as often theses sorts of user interactions span multiple views. If the conversation is left hanging, you would just allow it to timeout.
2) Yes, a single method with multiple faces requests in it is the correct way to test this. Take a look at the tests for an example for Seam, e.g. booking, and compare it to the path a user would take through the app.
I will take a look at those examples. Thanks again for all the guidance.
Thanks to your insight, Pete, and to the samples, things are going swimmingly. One more question though...I forgot to mention another case in the scenario I described--the case where no results are found for the search parameters provided.
The method that performs the search when the user hits the button is marked with @Begin. When the search comes back with nothing, I populate the FacesMessages, but I would think there really should be no active conversation (both conceptually and for performance) unless results are obtained and a particular widget is chosen. Is this a valid concern? If so, how can I end the conversation within the method marked with @Begin when no results are found? Or is there a more elegant way of addressing this?