ICEfaces
  1. ICEfaces
  2. ICE-8770

ace:gMap MandatoryResourceConfig non-functional

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces3 trunk revision# 32166

      Description


      When setting the mandatoryResource config for 'gMap' or 'org.icefaces.ace.component.gmap.GMap' and dynamically including ace:gMap on the page the component does not render.

      Test application is located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Manual/gMap
      Test page is located at /gMapMandResConf.jsf

        Activity

        Hide
        Arturo Zambrano added a comment - - edited

        After extensive investigation, I finally found out that the problem has nothing to do with the mandatory resource configuration, and that the problem is caused the the google code itself.
        This situation only happens when trying to load a gmap component dynamically, as the gMapMandResConf.jsf page does: it dynamically includes an xhtml document, containing a gmap, when the checkbox is on. When the script snippet produced by the renderer to initialize the component is loaded to the page via a dynamic update, the google maps API fails to work properly. In particular, it fails to download a number of required javascript resources required for gmaps to work. If the script to initialize the component is already present when the page is first loaded, then the google API successfully loads all other required resources from google's servers and the map is displayed.
        For now, the solution seems to be to initialize a dummy map when first loading the page, and then discarding it. This causes the gmaps API to (pre)load all external required resources as soon as the page is loaded. If the following code is either hard-coded in a script element on the page or added to the end of the gmap component scripts, it will solve the issue:
        new google.maps.Map(document.createElement('div'),

        {mapTypeId:google.maps.MapTypeId.ROADMAP, zoom:5, center: new google.maps.LatLng(0,0)}

        );

        Show
        Arturo Zambrano added a comment - - edited After extensive investigation, I finally found out that the problem has nothing to do with the mandatory resource configuration, and that the problem is caused the the google code itself. This situation only happens when trying to load a gmap component dynamically, as the gMapMandResConf.jsf page does: it dynamically includes an xhtml document, containing a gmap, when the checkbox is on. When the script snippet produced by the renderer to initialize the component is loaded to the page via a dynamic update, the google maps API fails to work properly. In particular, it fails to download a number of required javascript resources required for gmaps to work. If the script to initialize the component is already present when the page is first loaded, then the google API successfully loads all other required resources from google's servers and the map is displayed. For now, the solution seems to be to initialize a dummy map when first loading the page, and then discarding it. This causes the gmaps API to (pre)load all external required resources as soon as the page is loaded. If the following code is either hard-coded in a script element on the page or added to the end of the gmap component scripts, it will solve the issue: new google.maps.Map(document.createElement('div'), {mapTypeId:google.maps.MapTypeId.ROADMAP, zoom:5, center: new google.maps.LatLng(0,0)} );
        Hide
        Arturo Zambrano added a comment - - edited

        Committed fix to trunk at revision 32334.

        The fix consisted in normalizing the API resource registration in order to prevent the browser from requesting the resource again, causing incorrect behaviour in the client.

        Show
        Arturo Zambrano added a comment - - edited Committed fix to trunk at revision 32334. The fix consisted in normalizing the API resource registration in order to prevent the browser from requesting the resource again, causing incorrect behaviour in the client.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: