[JAVASERVERFACES_SPEC_PUBLIC-1021] Expose component local values in single key/value data structure Created: 23/Jun/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small


 Description   

Every ValueHolder JSF component has a local value. It would be nice to have access to these local values knowing only the name of component. Something like this. We could specify that the viewMap must be populated with references to the ValueHolder instances in the current view. Then, you could say:

ValueHolder comp = (ValueHolder) context.getViewMap().get("<your componentId>");

Look at the API for ValueHolder.

http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/ValueHolder.html



 Comments   
Comment by Jakob Korherr [ 23/Jun/11 ]

Nice idea. This would make the binding attribute kinda obsolete, right?

Comment by arjan tijms [ 05/Jul/11 ]

Just wondering, will this view map only contain ValueHolder instances or also other components? In case it also contains other components, it's perhaps a bit similar to:

ValueHolder comp = (ValueHolder) context.getViewRoot().findComponent("<your componentId>");

Nice idea. This would make the binding attribute kinda obsolete, right?

Well, with the binding attribute a backing bean receives an instance of a component without having to know its ID at all. This is handy since within a backing bean there might be situations where you can't know this ID and/or do not want to know it. So the binding attribute doesn't seem to be made obsolete if I understand the proposal correctly.

Comment by Hanspeter Duennenberger [ 07/Jul/11 ]

Why should that be on ViewMap? That would mean the ViewMap has to be cleared of these component references before state is saved.

Comment by Ed Burns [ 07/Jul/11 ]

HD> Why should that be on ViewMap? That would mean the ViewMap has to be
HD> cleared of these component references before state is saved.

Good point. It should really be on the FacesContext attributes Map.

Here is more from the reporter.

>>>>> On Wed, 6 Jul 2011 10:53:46 +0200, Rainer Sinkwitz said:

RS> Hi Mr. Burns,
RS> Thanks for your mail. Actually what you describe is possible and I use it
RS> as part of my IMHO kludgy solution. The key issue are the AJAX expressions
RS> and it seems I can either access the view for unsaved values or work with
RS> a copy of my model and extra code for loading and saving the copy against
RS> the model. Right now I think I should first update myself to JSF 2.0
RS> before I continue with any further proposal for this.

RS> For your information here is what I do right now: I make the UIComponent
RS> available as EL expression through a Map implementation with a only get()
RS> coded like
RS> public Object get(Object key)

{ RS> UIViewRoot viewRoot = FacesContext. RS> getCurrentInstance().getViewRoot(); RS> return viewRoot.findComponent(((String) RS> key)); RS> }

RS> So if I have that map in the session, then I can use an EL expressions
RS> like
RS> value="#

{viewMap['form:fld_pr_customer'].value.displayCity}

"

RS> ... and viewMap[...].value gives me the converted object since there is
RS> UIComponent.getValue()/setValue(). So I have already what you describe,
RS> and even as a JSF expression, but I still find this kludgy.

RS> Lets me again describe by basic setting: Most of our forms have a "View"
RS> and an "Edit" mode, so that concurrent editing can be prevented with
RS> global locks. The main issue is the "Cancel" functionality which instead
RS> of updating the model must revert the form to it. Since the model is an
RS> attached JPA entity, JSF phase 4 must be suppressed. I currently do this
RS> with 'immediate="true"' on the cancel button and an action method that
RS> replaces the entire view with an empty one, then calling RenderResponse()
RS> to skip to phase 6, which in turn rebuilds the view and reloads the values
RS> from the model.

RS> So far so good, but the complication begins when I do AJAX updates with
RS> JBoss RichFaces Ajax4Jsf updating some dependent fields from unsaved
RS> values. Here it is that I need to use the above expressions.

RS> An alternative solution would be to let the form work against a copy of
RS> the JPA entity. Then AJAX could update the copy instead and use normal
RS> expressions against the copy. But then I need to do all the field copying
RS> from JPA entity to the copy and back and then somebody adds a new field
RS> and misses the copy code. Not a nice solution either.

RS> Anyway, thanks for your response, with best regards, Rainer

Comment by Hanspeter Duennenberger [ 08/Jul/11 ]

EB> Good point. It should really be on the FacesContext attributes Map.

And even in FacesContext it needs to be cleared whenever ViewRoot changes. That remembers me to something we discussed some time back - a View-related-Request scope. That is something that lifes during a request but only as long as the ViewRoot does not change. I guess that could easily be handled on FacesContext and that would be the place for such things as the references to EditableValueHolders.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Generated at Fri Jul 29 20:53:29 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.