• Post Reply Bookmark Topic Watch Topic
  • New Topic

Getting Backing Bean From Converter from Faces Converter  RSS feed

 
ilhan aksu
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a ccomposite compenent which contains SelectOneMenu Control and it's Backing Bean to Load Data of SelectOneMenu Control . And also have a custom converter for SelectOneMEnu control. Now I want to get BackingBean from 'getAsObject' method of FacesConverter. When I post the page component doesn't bind the value to CDI beans field. My Converter and other codes are below.

This is the Converter Class.




The problem is ; I can not get the BackingBean ( AccountComponent) of composite control. I mean 'vex.getValue' method returns NUll. And because of this reason I can not access to selected object of SelectOneMenu control. My all other codes are below.

THe Composite control.



BackingBean of Composite Control.



And Last one is my JSf page where I use the component.





Thanks.
 
Tim Holloway
Bartender
Posts: 18781
74
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Ilhan!

I think you are making this over-complicated.

A JSF Converter is a mechanism for converting values. The getAsObject() method returns the value that JSF will (automatically) inject into the target property when a form is submitted. The getAsString converts a target property value to a String, since HTML is a text-based encoding and therefore cannot work with the raw property value (unless that value is itself a string).

Note that I never mentioned backing beans. The bean itself is simply the container for a property and JSF gets/sets that property's value. It is part of the Controller part of the JSF Model/View/Controller architecture and is usually the closest thing the average application programmer will come to actually coding a Controller in JSF, since JSF's Controllers are pre-written as part of the tag and FacesServlet frameworks. Only Models and Views are coded by application programmers.

Normally the only thing a Converter should do is convert. It really shouldn't be referencing beans, properties, or JSF internal structures. JSF is designed to work on a POJO basis, and the Converter interface is no exception.

Beyond that, I don't recommend accessing the EL services explicitly. The entire EL mechanism changed radically between JSF version 1 and JSF version 2 and everything written to talk to the JSF version 1 EL subsystem broke. I had some stuff that used other JSF internals (a custom binary tag), and it required an almost total rewrite even though I didn't do much with the EL mechanism myself.

To repeat, JSF was designed to work with POJOs and there are essentially No User-servicable Parts Inside, as it says on the TV set. Any time you find yourself using any java.faces class or interface other than the DataModel or SelectItem classes, you should stop and think very carefully.
 
ilhan aksu
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,
Firstly thank you very much for your replay .   I'm new in JSP and JAVA world  ,my baground is on .Net and C# developent .   So my questions might be basic/silly ,  sorry about that.:( .  
As you said  what I want to do is should not be that complicated . I need to create component which loads and stores own   data   (List of Account) and shows is in select HTML element.   So I am using fgetAsObject   method  to get selected account from faces component list after forms is submited.     I've googled  lots of time  for a 2 weeks. But I couldn't find a suitable solution.     Could you give me some resouces ,advices to learn JSF . It might be video totorials, books,blogs etc.    

Thanks .
 
Tim Holloway
Bartender
Posts: 18781
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of my favorite introductions to JSF was an IBM DeveloperWorks series called "JSF for Nonbelievers". Although written for JSF version 1, much of what it taught was still good advice for JSF2. Unfortunately, that set of articles isn't online anymore last time I checked.

I have Kito Mann's Javaserver Faces In action book, although that, too is dated. I started with JSF in 2006, so my learning resources are ancient, I'm afraid.

The main things to keep in mind are that:

1. JSF is a virtually pure implementation of the Model/View/Controller paradigm. Models contain data, Views present data, and Controllers bi-dorectionally synchronize the values of data between Model and View. That is, change the Model, the View gets updated. Change the View, the Model gets updated.

2. JSF was designed to work with POJOs. It employs Inversion of Control. Those are both basic Java concepts that you should learn well. Earlier web frameworks such as Struts required Model, View, and/or Controller components to implement framework-specific interfaces (or subclasses). That reduced the portability and reusability of the components, and also meant that changes in framework internals was likely to require applications to be changed as well. POJOs have no framework dependencies. They operate strictly on being queried by "get" methods and updated by "set" methods. The framework-specific stuff is all in the framework itself, not in application code. That's the Inversion of Control concept. The bean doesn't look for stuff, the stuff gets delivered to it automatically.

3. JSF is based on a specific lifecycle. I encourage you to find one of the lifecycle maps on the web, since what I'm about to say comes strictly from my flawed memory and is almost certainly incorrect/missing things, but the cycle occurs once per client HTTP request/response cycle and is roughly like this:

i. form is submitted. A Component Tree is built (or retrieved) by JSF. This Component tree serves as the reference for consuming and producing client views (HTML).
ii. incoming form values are validated. If any form value is invalid, the lifecycle is short-circuited.
iii. After all form values are determined valid, they are converted from HTML text to the proper backing property type (automatically, if possible, using a Converter, if not). The conversion is driven in part by introspection of the bean to determine the target property type. The converted values are then injected by JSF into the appropriate bean property. Somewhere in here the incoming value is compared to the current value and if they differ AND there's a ValueChangeListener for the property, that listener is invoked. The Listener should not attempt to change the property itself - JSF does that. What the listener is for is to handle value change events. I use this to cascade selection lists such as cases where you have a country, state, and city controls and changing the higher-level control invalidates the lower-level controls.
iii. Once all the bean properties have been updated, the action processor is invoked. The action processor is where your business logic is handled. Database work, for example.
iv. After the action processor has finished, the updated Model values (which may have been changed by the action method) are posted back to the client as part of generating an updated View. JSF has an abstraction layer that takes the Component Tree and renders it as HTML. Originally other output options were considered as well, but in practice, JSF is almost alway done in HTML at the moment.

4. This is very important. JSF get/set methods must be idempotent. In other words, no matter how many times you invoke a get/set method, you should end up with the same results. Get/set methods may be invoked up to about 6 times per request/response cycle, so any side effects would produce unpredictable results.

Those are probably the most important things to know. Other than, as I have previously said, since JSF is a POJO framework, the more JSF-specific code you write, the more likely you're not doing it right.

In your case, I think you're trying to use a Converter as a sub-Controller. That's not what Converters are for. Converters are invoked by Controllers, but they don't set or get values, only convert them to and from String (HTML) values. It's the Controller's job to actually invoke the backing bean's set/get methods and the Controller is a pre-written part of JSF itself.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!