ICEfaces
  1. ICEfaces
  2. ICE-9223

Normalize the way ace:gMap handles its state

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: EE-3.3.0.GA, 4.0.BETA, 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Any
    • Salesforce Case Reference:

      Description

      At the moment, ace:gMap has some hidden input fields that submit to the server state information like zoom level, lat, lng, etc. that the user modified by directly interacting with the map. These input fields aren't decoded in the standard way right now, but instead there's a mechanism in the Render Response phase that attempts to update the state of the component, based on the submitted values of these input fields and the old values of these attributes in the component. However, this mechanism is far from perfect, since it is not able to update the properties in the bean that are bound to these attributes, in some cases, and it fails to correctly update these attribute values in some other cases. Moreover, doing these updates in the last phase of the lifecycle can lead to problems when applications try to modify such values in the Invoke Application phase, which is the normal fashion. The right thing to do is to decode these state values in the Apply Request Values phase, as is the case with all input components.

        Activity

        Arturo Zambrano created issue -
        Arturo Zambrano made changes -
        Field Original Value New Value
        Assignee Arturo Zambrano [ artzambrano ]
        Arran Mccullough made changes -
        Salesforce Case Reference 5007000000T64cpAAB
        Ken Fyten made changes -
        Component/s ACE-Components [ 10050 ]
        Arturo Zambrano made changes -
        Summary Convert ace:gMap into a true input component so that it handles its state correctly Improve the way ace:gMap handles its state
        Arturo Zambrano made changes -
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Arturo Zambrano made changes -
        Description At the moment, ace:gMap extends from UIPanel. However, it does have some hidden input fields that submit to the server state information like zoom level, lat, lng, etc. that the user modified by directly interacting with the map. Since, the component doesn't extend from UIInput, these input fields aren't decoded in the standard way, but instead there's a mechanism in the Render Response phase that attempts to update the state of the component, based on the submitted values of these input fields and the old values of these attributes in the component. However, this mechanism is far from perfect, since it is not able to update the properties in the bean that are bound to these attributes, in some cases, and it fails to correctly update these attribute values in some other cases. Moreover, doing these updates in the last phase of the lifecycle can lead to problems when applications try to modify such values in the Invoke Application phase, which is the normal fashion. The right thing to do is to make acE:gMap extend from UIInput, so that these state values are decoded and applied in the Apply Request Values phase, as is the case with all input components. At the moment, ace:gMap has some hidden input fields that submit to the server state information like zoom level, lat, lng, etc. that the user modified by directly interacting with the map. These input fields aren't decoded in the standard way right now, but instead there's a mechanism in the Render Response phase that attempts to update the state of the component, based on the submitted values of these input fields and the old values of these attributes in the component. However, this mechanism is far from perfect, since it is not able to update the properties in the bean that are bound to these attributes, in some cases, and it fails to correctly update these attribute values in some other cases. Moreover, doing these updates in the last phase of the lifecycle can lead to problems when applications try to modify such values in the Invoke Application phase, which is the normal fashion. The right thing to do is to decode these state values in the Apply Request Values phase, as is the case with all input components.
        Arturo Zambrano made changes -
        Summary Improve the way ace:gMap handles its state Normalize the way ace:gMap handles its state
        Arturo Zambrano made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 3.4 [ 10770 ]
        Ken Fyten made changes -
        Fix Version/s EE-3.3.0.GA [ 10572 ]
        Ken Fyten made changes -
        Fix Version/s 4.0 [ 11382 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arturo Zambrano
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: