Google Maps in Siebel (Open UI): The Penultimate Edition - Part 2

Welcome to the second part of our 'penultimate' edition of Google Maps in Siebel Open UI.

In the first part, we focused on the scaffolding, used templates to create a custom PM and PR for the SIS Account Entry Applet and downloaded and registered the colorbox plugin.

Today we will look at the actual implementation, starting with some requirements:
  • As stated in part 1, the code should be generic enough to work with all form applets that display address data
  • The solution should be SRF-independent.
  • A clickable map icon should be displayed next to the address fields.
  • When the icon is clicked, the map of the address displayed in the applet should be shown in a colorbox iFrame.
So, let's get to work:

4. Implement the Presentation Model

The purpose of a presentation model is to capture the business logic behind the scenes. In our example, the PM's task will be to extract the address information and create the link which leads to the map vendor's web site.

The following screenshot shows the custom PM's Init method and two "event handlers":

Click to enlarge.
The above code does the following:
  • Declare a new property "sMapHTML" to hold the HTML code for the link.
  • Declare handler methods for the ShowSelection and FieldChange API methods. Remember that "sequence:false" means "post".
  • Declare a custom method CreateMapHTML
  • The two "post" event handler methods simply invoke the CreateMapHTML function which returns the link HTML and then set the sMapHTML property value.
And here is the CreateMapHTML function in all its glory (see below for details):

Click to enlarge.
The above function does the following:
  • Declare the map base URL and parameters.
  • Get the controls for the current applet
  • Declare an object addressControls to hold the address related controls. Initialize each element with a "search string" such as "addr" or "postal". These search strings are meant to be used to locate address related controls in the applet. This is an experimental SRF-independent alternative to applet user properties and is of course problematic when address controls have "meaningful" names such as "HTML Text 2" or similar...
  • Iterate through the controls of the applet and compare the name of each control to the "search string". If the control name contains the search string, the control object will be added to the addressControls object.
  • Store the addressControls object as a property for easy access from within the PR.
  • Verify that we actually have an address using the control representing the street address.
  • Concatenate all address fields to a full address string to be used on the map page.
  • Generate the image link HTML using the full address string.
As discussed above, this educational example tries to demonstrate SRF-independency. If the names of the applet controls do not contain the "search strings", the above solution will not work. I have demonstrated how to use applet user properties to "broadcast" information from the repository to the PM in an earlier post.

In addition, one might want to consider externalizing all hardcoded stuff such as the map base URL, its parameters and the HTML snippets. Using constants similar to the as-delivered Open UI API would be a good idea.

The example presentation model file can be downloaded here.

5. Implement the Physical Renderer

Now it's time for the PR code. First, we modify the line which calls the define function to resemble the following (modifications in bold font).

define("siebel/custom/GoogleMapBoxPR", ["siebel/phyrenderer","siebel/custom/colorbox/jquery.colorbox-min"], function(){

This modification ensures that the colorbox library is always loaded with the physical renderer. This is an alternative to registering the library with the manifest and ensures that the colorbox code is only loaded when it is really needed.

The following screenshot shows the remainder of the PR code (explanation below):

Click to enlarge.
The above code does the following:
  • In the PR's Init method, use the AttachPMBinding method to attach the local ShowMapIcon method to the sMapHTML property. This ensures that the ShowMapIcon method is invoked every time the property is altered.
The ShowMapIcon method does the following:
  • Get the HTML generated by the PM
  • Remove any current instances of the image link using the anchor's name attribute.
  • Get the addressControls object from the property.
  • Obtain the object representing the street address control.
  • Get the value of the control's name attribute.
  • Insert the HTML string after the control.
  • Call the colorbox method upon the link. Note the iframe:true specification which is required for Google maps.
The example physical renderer file can be downloaded here.

6. Test

The result of the above code is a map icon displayed next to the street address control in a form applet:


The icon will only be displayed if there is an address available.
When the icon is clicked, a colorbox iFrame will open and display the map:

Click to enlarge.
To test the genericity of the code, register the PM and PR with other form applets (such as the Contact Form Applet) which display address data. Again, the code is experimental and not production-ready. Using applet user properties to specify the address field names might be a much safer way but alas is SRF dependent.

Summary

Thanks again to Mattias for the inspiration to bring the Google maps example to IP 2013 (or higher). I took the liberty of tweaking the requirements hoping to trigger some out-of-the-box thinking.

As a courtesy, you can download the PM and PR code (code examples provided on Siebel Essentials are for educational purposes only! Do not use this code in production! If you do so, it is at your own risk!) here:

The example PM can be downloaded here.
The example PR can be downloaded here.

What is your approach to the "maps requirement"? Please find the comments.

have a nice day

@lex

תגובות

פוסטים פופולריים מהבלוג הזה

FINS Data Transfer Utilities

SBL-BPR-00191: The rowId of the active row of the primary buscomp '%1', '%2', does not match the Primary Id

Profile Attributes and Open UI