javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-1021

Expose component local values in single key/value data structure

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Lifecycle
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_small importance_small

      Show
      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

        Activity

        Hide
        Jakob Korherr added a comment -

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

        Show
        Jakob Korherr added a comment - Nice idea. This would make the binding attribute kinda obsolete, right?
        Hide
        arjan tijms added a comment -

        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.

        Show
        arjan tijms added a comment - 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.
        Hide
        Hanspeter Duennenberger added a comment -

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

        Show
        Hanspeter Duennenberger added a comment - Why should that be on ViewMap? That would mean the ViewMap has to be cleared of these component references before state is saved.
        Hide
        Ed Burns added a comment -

        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

        Show
        Ed Burns added a comment - 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
        Hide
        Hanspeter Duennenberger added a comment -

        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.

        Show
        Hanspeter Duennenberger added a comment - 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.
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Minor

        Show
        Manfred Riem added a comment - Setting priority to Minor

          People

          • Assignee:
            Unassigned
            Reporter:
            Ed Burns
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: