JSF, EL, Managed Beans - How to tell what the getter & setter signatures are? - jsf

With JSF, Managed Beans, & EL 2.2 I know generally that an expression of the form:
#{bean.value}
Will map to a corresponding set of functions in a managed bean class like so:
#ManagedBean
class Bean {
private String value;
public String getValue() { return value; }
public void setValue( String s ) { value = s; }
}
It is also possible to get and set properties of a map:
#{bean.value['key']}
Backed by something like:
#ManagedBean
class Bean {
private Map<String, Boolean> kvMap;
public boolean getValue( String key ) { return kvMap.get( key ); }
public void setValue( String key, boolean value ) { kvMap.put( key, value ); }
}
So far so good.
I'm finding as I spend more time with JSF however that I'm trying to write reusable chunks of code. Specifically, small blocks of xhtml in <ui:composition> blocks that I can include via <ui:include>. What's more, many of the more useful things for me are things like nested sets of checkboxes (our UI designer is just gaga over them ;-), and there <ui:repeat> becomes very handy.
Invariably, in order to use <ui:repeat> and <ui:include> without an ungodly amount of typing, I've been using aliases, either created via <ui:param> or inline with something like the var attribute of <ui:repeat>.
As I've been writing more and more nested UIComponents, particularly things that get their values from maps within maps, I'm finding it harder and harder to deduce the correct setter method signature that JSF will look for when submitting a form (for some reason writing getters seems to be more natural).
My question for you gurus then is:
Is there some way to get JSF to tell me what it expects a setter signature to look like? Since JSF generally doesn't complain about an expression that resolves to a getter-only (thinking it is a read-only property), I find the lack of feedback frustrating and it seems to require a lot of fiddling with different method signatures before I finally hit that magic right one.
I'm hoping there's some technique, say a FacesContext... query at runtime or looking in some compiled intermediate like a class file that would point me to the correct setter signature for a deeply nested property. If there is such a thing I think it would save me a lot of time trying to figure out how to get a setter constructed by trial and error.
Hopefully I've articulated clearly enough what I'm after, thanks in advance for your replies.

I understand that your question basically boils down to "How should a setter for a Map look like?".
The answer is simple: you don't need any one. EL uses the put() method on the Map itself. You only need to provide a getter for the whole Map. On getting map values, EL will use the get() method of the Map itself. This is all behind the scenes done by the builtin MapELResolver.
So this should do:
#ManagedBean
class Bean {
private Map<String, Boolean> kvMap;
public Map<String, Boolean> getValue() { return kvMap; }
}
which is to be used as #{bean.value['key']} or #{bean.value.key} if the key doesn't contain periods. You can just use it in input components as well.
<h:selectBooleanCheckbox value="#{bean.value.key}" />
As to the tooling, well, the JBoss Tools plugin for Eclipse has good EL autocomplete support for normal javabeans, but it can't autocomplete map keys. Further Eclipse has its own facilities to autogenerate bean properties along with getters and setters based on a list or existing properties.

Related

Get rendered html code in Backing Component from Composite Component

How can I get the posted form data in the backing component in the
processUpdates method?
#Override
public void processUpdates(FacesContext context) {
//get here rendered html code
}
Or can I get the posted form data in the decode method?
[Edit]:
My goal is to get the posted form data - Not to get the generated html code (Sry I wasn't precisely)
It is unclear what you want to achive, yet. I mean, at high level.
UIComponent.decode and processUpdates are medium-level lifecycle APIs which should be overriden when you want to extend the framework.
If you just need to use the framework, you need a managed bean, not a backing component.
Furthermore, generally only components that extend UIInput need to hook in those phases, because they are bound to a value="#{...}" value expression (which in turn refers to a managed bean, in most cases), and need to synchronize those values with the bound expression.
I suspect you are uselessly complicating your life: hooking into medium or low-level APIs is a real pain if you don't have an excellent understanding about how the framework operates.
Anyway, the standard request parameters decode into input component is this:
String clientId = this.getClientId(context);
Map<String, String> requestMap = context.getExternalContext().getRequestParameterMap();
String newValue = requestMap.get(clientId);
if (newValue != null)
{
this.setSubmittedValue(newValue);
}
Please, post the full xhtml facelet code (not the composite one, but the facelet using that composite), so I can understand where you want to go and I can try to point you to the right tool to use.

GenericDTO and JSF

I am currently reading Adam BienĀ“s book "Java EE Patterns: Rethinking Best Practices".
In chapter "Transfer Object and Data Transfer Object" on page 273 he introduces a generic DTO.
See also: http://www.adam-bien.com/roller/abien/entry/no_duplication_no_decoupling_the
A genericDTO does not follow the bean conventions.
I was wondering how to use generic DTO together with JSF.
JSF if not dynamically used (build components on the flight) makes use of java-beans to bind values to UI-Components (for example #{beanA.beanB.myValue}).
A genric DTO does not provide individual getters for attributes or relations.
Instead i would have to call getters with a string parameter.
So accessing it via #{beanA.beanB.myValue} is not possible in JSF (1.2).
Is it possbile to use the genric DTO pattern together with JSF?
Regards,
Max
I have not read the entirety of Adam's article, so can not comment on when using this pattern is appropriate. However, EL-expressions do support maps with the . or [] operators, i.e. if you have:
#Named
public class MyBean {
private Map<String, Object> attributes;
public Map<String, Object> getAttributes() {
return attributes;
}
}
you can use
#{myBean.attributes.name}
or
#{myBean.attributes['name']}
to get or set the map entry with key "name".

JSF 2.1 - getting FacesContext strategy

I am developing webapp where my MVC controller is JSF 2.1. I have several methods that are based on
FacesContext.getCurrentInstance()
I use this to
put/retrieve values from Flash scope
add messages on view
get request params map
examples:
public void addInfoMessage(String title, String description){
FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO,title, description));
}
and
public void putFlashMessage(String code, String value){
FacesContext.getCurrentInstance().getExternalContext().getFlash().put(code, value);
}
etc.
I'm just wondering where is proper place to put this methods if I use this on every single managed bean? I consider two options:
a) create class "JSFUtils", where all method are public and static
b) create super class "ManagedBean" with no declared scope and no declared #ManagedBean annotation, but with these public methods. Every managed bean should be child of these class so it will have inherited these methods.
An utility class is the recommended approach. Instead of reinventing your own, you can use an existing JSF utility library, such as OmniFaces which has Faces and Messages utility classes for the purpose.
String foo = Faces.getRequestParameter("foo");
Messages.create(summary).detail(detail).add();
Messages.addGlobalInfo(summary); // Without detail.
Faces.setFlashAttribute(key, value);
You can indeed also abstract it away as a "super bean", but this is not reusable and you would keep repeating yourself in every JSF project. Also, a class can extend from only one class. So if your bean happen to need to extend from another super class, then you're lost.
I would recommend a utility class for the purpose simply because you allow the flexibility to extend other useful classes, such as those that have some common logic that you'd like to share across other beans.
Having said that, a JSFUtils class can grow quite cluttered with time with many many methods and can become very unmanageable. It would be better to categorize the util methods and put them in separate static utility classes.

Bind h:selectBooleanCheckbox value to int/Integer instead of boolean/Boolean

I have a <h:selectBooleanCheckbox value="#{someBean.prop}"> where prop is a property of type int. Is it really not working straight away? Do I have to implement a custom converter to convert Boolean to int? Does anyone happen to have converter code for that at stock? I read that there is some bug in JSF 2.0 that prevents converters for <h:selectBooleanCheckbox> to be processed. Can anyone confirm that?
I use MyFaces 2, Tomahawk and Tomcat 6.
The <h:selectBooleanCheckbox> should, as its name say, be bound to a boolean or Boolean property. Nothing else. That it allows a converter attribute is actually a bug in the spec. It should never have allowed it.
The problem is more in your model, why would you use an int to represent a boolean state? Change your model to let it be a fullworthy boolean.
If changing the model isn't an option for some reason (a 3rd party API, a stupid architect, or stupid business restrictions, etc), then wrap the model getter/setter in the backing bean like follows
public boolean isChecked() {
return someModel.getSomeInt() != 0;
}
public void setChecked(boolean checked) {
someModel.setSomeInt(checked ? 1 : 0);
}
and use it instead as <h:selectBooleanCheckbox value="#{bean.checked}" />.
just to say MySQL doesn't have boolean as field type choice, and it could be an example for this need.
You can set field as tinyint in MySQL. Actually problem is getting method name when you create a boolean variable. Use method name getChecked() instead of isChecked().

How can i send a parameter to be used in the #PostConstruct method of a backing bean?

I need to preload some data to be displayed when the page loads. The initialization steps are performed on a #PostConstruct-annotated method but now i need to use a parameter in order to get the data.
What i'm trying to do:
#PostConstruct
public void init()
{
List data = getDataFromDB(parameter) /*Need to read a parameter created somewhere else*/
}
Is there a way to achieve this?
Thanks in advance
It's kind of hard to say what you mean by "a parameter set somewhere else". I will assume that "somewhere else" means "sent from browser by HTTP". In such case you should create a standard property in your managed bean and:
in JSF 2.0 you could annotate it with #ManagedProperty("#{param.nameOfParameterToRead}")
in JSF 1.2 and less - use managed-property element in your bean description (faces-config.xml).
Like this:
#ManagedBean
#RequestScoped
class MyManagedBean {
#ManagedProperty("#{param.id}")
public Integer id;
#PostConstruct
public void init(){
data = getDataFromDB(id)
}
// setters and getters (mandatory, even though annotation is on an attribute!!!)
}
Careful: injecting properties does not use JSF converters, so it is best to inject strings and take care of conversion in your own code.
how about reading from Properties file, or fetching List from DB ??

Resources