• Post Reply Bookmark Topic Watch Topic
  • New Topic

PPR with two tr:selectOneChoice problem  RSS feed

 
hassan ali
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi


I am reading this book
Packtpub.Apache.MyFaces.1.2.Web.Application.Development


trying to apply PPR on two tr:selectOneChoice

Number one for car company when changed

Second one load car model that belongs to that company.

using valueChangeListener

this is form in jsp file

<tr:form >
<t:saveState value="#{daata}"/>

<c:if test="#{empty autoSubmit}">
<c:set var="autoSubmit" value="false" />
</c:if>
<tr:selectOneChoice id="car"
autoSubmit="true" value="#{daata.car}" valueChangeListener="#{daata.updatemodel}">
<f:selectItems value="#{daata.car}" />

</tr:selectOneChoice>


<tr:selectOneChoice value="#{daata.model}" partialTriggers="car" >
<f:selectItems value="#{daata.model}" />

</tr:selectOneChoice>
</tr:form>

this is updatemodel model function


public void updatemodel(ValueChangeEvent event) {

CoreSelectOneChoice s = (CoreSelectOneChoice) event.getSource();

if(s.getValue().equals("Peugeot")){
Map mods= new HashMap<String, String>();
models.put("405","405");
models.put("406","406");

setModel(models);

}

models is HashMap has it setModels and getModels
and reload fine in page start
but after choosing company in first tr:selectOneChoice it gives me this error


javax.faces.application.ViewExpiredException: /ajax.jspNo saved view state could be found for the view identifier: /ajax.jsp

ajax.jsp(51,4) '#{daata.model}' Error reading 'model' on type daata



kindely help
thanks



 
hassan ali
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i found this

update method must use FaceContext to change values of model like this


public void updatemodel(ValueChangeEvent event) {
CoreSelectOneChoice s = (CoreSelectOneChoice) event.getSource();


FacesContext f=FacesContext.getCurrentInstance();
CoreSelectOneChoice element = (CoreSelectOneChoice)f.getViewRoot().findComponent("model");

if(s.getValue().equals("Peugeot")){


Map modeling= new HashMap<String, String>();
modeling.put("305","305");
modeling.put("405","405");

setModel(modeling);


element.clearCachedClientIds();
element.setValue(modeling);
}

if(s.getValue().equals("Fiat")){


Map modeling= new HashMap<String, String>();
modeling.put("128","128");
modeling.put("126","126");

setModel(modeling);


element.clearCachedClientIds();
element.setValue(modeling);
}

}
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Code and XML formatted as a general message text can be very hard to read. If you use our "Code" button to wrap it with code tags it will help a lot.

I don't like that approach. As a general rule, getting FacesContext or locating View elements from the Model are things I discourage. They make the code more complex, more dependent on the framework and the framework version, and the code generally cannot be tested via stand-alone unit testing.

Here's an alternative that works well for me when cascading 2 selection lists:

In the valueChangeListener for the parent control, I zap the selection model for the dependent control (usually, that means I set it to null). I also zap the dependent value, since otherwise it would probably be invalid, seeing as how the list of options is now empty/missing.

In the "get" accessor method that returns the SelectItem collection of the dependent control, I add logic to see if the selection model is present or not. If it isn't, I build it and cache it, so I only have to build it as needed. I then return the SelectItem list from cache.

When I do this, not only am I spared having to get the FacesContext and add JSF-specific code to the process (it's all POJO code), but I get an added benefit in that when the page is first displayed, the same functionality that gives me updates to the dependent selection list also gives me the initial dependent selection list. So no need to do awkward things with constructor or postconstruct methods. Most importantly this means that if my list is build from persistent storage, the retrieval mechanisms will have been initialized by then, which is more that a constructor can boast.
 
hassan ali
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks

my i have example or matrial(url..) to read about it.

 
hassan ali
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi

for clearing your massage is that what you are trying t say like this url

http://weblogs.java.net/blog/lamineba/archive/2011/05/12/implementing-cascading-dropdown-jsf-2-0
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!