Is it bad to use JSF #view.attributes map instead of #viewScope to store view scoped application data?

Question

I was suggested by someone to use #view.attributes map to store view scoped data that I need to survive even after session destroys(with client side state saving). Now that it works perfect for my requirement but I just want to make sure this is not a bad practice or bad thing to do.

I found that this works exactly like viewscope map except for it survives the data even after user session was destroyed.

Answer 1

In JSF versions prior to 2.0 it was only possible to store objects in the view only by using UIViewRoot.set/getAttribute.

However in JSF 2.0 a separate view scope was introduced that can be used in EL via #{viewScope} or programatically using UIViewRoow.getViewMap(). Using the view scope is the recommended way to go. It is implemented using a Map that is kept in the UIViewRoot and is serialized the same way as the view attributes in thew view state so it has the same life as the view attributes.

UPDATE

According to Leonardo Uribe from MyFaces team:

In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder.

So it looks like the portable way is to use the attributes map in UIViewRoot.

Answer 2

using viewScope is recommended. avoid using view root (component in general) attributes for two reasons:

1. in theory, there exists the possibility that you overwrite a view root component attribute. in practice it is not possible since attribute keys are implemented with an enum (at least in mojarra)

2. UIComponentBase.getAttributes returns a particular Map implementation: AttributesMap. this implementation, at first, checks if exists a method with the same name of map key, in the component. and if not not, it checks the internal map. if again it is not found, it checks the component ValueExpression map. so it is not efficient at all, and, in very particular case, can lead to infinite recursion.

take a look at AttributesMap.get, in example:

public Object get(Object keyObj) {
    String key = (String) keyObj;
    Object result = null;
    if (key == null) {
        throw new NullPointerException();
    }
    if (ATTRIBUTES_THAT_ARE_SET_KEY.equals(key)) {
        result = component.getStateHelper().get(UIComponent.PropertyKeysPrivate.attributesThatAreSet);
    }
    Map<String,Object> attributes = (Map<String,Object>)
          component.getStateHelper().get(PropertyKeys.attributes);
    if (null == result) {
        PropertyDescriptor pd =
                getPropertyDescriptor(key);
        if (pd != null) {
            try {
                Method readMethod = pd.getReadMethod();
                if (readMethod != null) {
                    result = (readMethod.invoke(component,
                            EMPTY_OBJECT_ARRAY));
                } else {
                    throw new IllegalArgumentException(key);
                }
            } catch (IllegalAccessException e) {
                throw new FacesException(e);
            } catch (InvocationTargetException e) {
                throw new FacesException(e.getTargetException());
            }
        } else if (attributes != null) {
            if (attributes.containsKey(key)) {
                result = attributes.get(key);
            }
        }
    }
    if (null == result) {
        ValueExpression ve = component.getValueExpression(key);
        if (ve != null) {
            try {
                result = ve.getValue(component.getFacesContext().getELContext());
            } catch (ELException e) {
                throw new FacesException(e);
            }
        }
    }

    return result;
}

---

thinking about your requisite, it makes little sense, at least from a webapp point of view. view state remembers component states: component model values that are changed from inital state and are to be processed next. if these values have not to be processed then there's no need to be rembered for a long time. we can think about them as "transient". conversely, if they have to be processed and remembered for a long time, persistence is the way. indeed i can't think a single case for this kind of data to survive for a longer time than session, and shorter than forever (persistence).

can you tell us a real life example?

the best example that comes in my mind is remember the active index for a tabView or an accordion, but this value can (and should) be persisted, if it is important.

however every problem has a solution, the first thing i can think is that you may implement a custom scope that stores these values in application scope using a specific cookie (client) value as key.