Changeset 19927 in main
- Timestamp:
- 03/02/20 11:59:30 (2 years ago)
- Location:
- trunk/ibisph-view/src/main/webapp
- Files:
-
- 1 added
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/ibisph-view/src/main/webapp/WEB-INF/config/spring/common.xml
r19916 r19927 311 311 <bean id="commonContentBasePathModelMap" class="org.ibisph.modelmap.SimpleGetModelMap"> 312 312 <description> 313 Used by some XSLT to dynamically access the 2ndardy XML 314 files as well as leaflet map and kendo json files. 315 Injected into the main Page.xslt. 313 Used by Java code to access remote XML files (like query modules) 314 and is passed into the XSLT enviro to dynamically access the 2ndardy 315 XML files (like community profile reports that loop a set of IPs) 316 as well as leaflet map and kendo json files. This value is injected 317 into the common alternate model maps with a handle defined in /Page.xslt. 316 318 </description> 317 319 <property name="modelMapKey" value="ContentBasePath"/> … … 329 331 If the webappBaseRequestPath is blank then this model map will build 330 332 the value using the webapp's server path and servlet context. 333 334 Why Needed ?: IBIS tries to be a build once deploy many webapp. The 335 webapp can be deployed into different enviros stand along server or 336 the recommended reverse proxy. The request paths can't be root 337 relative because if app server only with mulitple apps or non dns 338 specific mapping proxy the context is needed. If generic, hard coded 339 context is added (ibisph-view) then all deployments would need "that" 340 mapping. The implemented solution for all non relative requests is 341 to use a variable requset prefix value. This is more complex when 342 building page UI request URLs but not much more work compared with 343 hard coding a context in the request's URL. 331 344 </description> 332 345 <property name="modelMapKey" value="WebAppBaseRequestPath"/> -
trunk/ibisph-view/src/main/webapp/js/L.LayerSets.js
r19700 r19927 64 64 // the work. It adds/sets the properties then kicks things off via the 65 65 // _addLayer(). 66 // GARTH TODO: maybe rename: webappContextPath to webappBaseRequestPath??? 66 67 ,initialize: function 67 68 ( -
trunk/ibisph-view/src/main/webapp/js/jquery.leaflet.js
r19338 r19927 171 171 options.layerSets.selectionLayerSetSelectionType = options.selectionLayerSetSelectionType; 172 172 } 173 // GARTH TODO: maybe rename: webappContextPath to webappBaseRequestPath??? 173 174 var layerSets = new L.LayerSets(options.layerSets, options.webappContextPath, infoPanelControl.getContainer()); 174 175 layerSets.addTo(leafletMap); -
trunk/ibisph-view/src/main/webapp/xslt/html/community/Page.xslt
r19918 r19927 19 19 <description> 20 20 Community profile base XSLT. 21 22 Since this XSLT is needed for all community pages even though the 23 facts page is HTML_CONTENT implemented CSS via XSLT like: 24 [xsl:param name="Page.htmlClass" select="'Community'"/] 25 [xsl:template name="Page.specificCSS"] 26 [link rel="stylesheet" type="text/css" href="{$ibis.baseRequestPath}css/Community.css"/] 27 [/xsl:template] 28 29 For facts could have used for the XML elements for Topic CSS but this 30 only covers the facts and not all community report type requests. 31 HTML_CLASS]Community[/HTML_CLASS] 32 [OTHER_HEAD_CONTENT] 33 [link ibis:href="css/Community.css" rel="stylesheet" type="text/css"/] 34 [/OTHER_HEAD_CONTENT] 21 35 </description> 22 36 </ibis:doc> … … 222 236 <script type="text/javascript" src="{$ibis.baseRequestPath}js/InputSelections.js"/> 223 237 <script type="text/javascript"> 224 var webappContextPath = "<xsl:value-of select="$ibis.baseRequestPath"/>"; 225 var dimensionName = "<xsl:value-of select="$Page.dimensionName"/>"; 238 var dimensionName = "<xsl:value-of select="$Page.dimensionName"/>"; 226 239 227 240 var selectionMapDialog; -
trunk/ibisph-view/src/main/webapp/xslt/html/topic/HTMLContentPage.xslt
r19916 r19927 12 12 <ibis:doc> 13 13 <name>html/topic/HTMLContentPage</name> 14 <summary> 15 </summary> 14 <summary>Provides topic specific IP selection list processing</summary> 16 15 <description> 16 Topic CSS NOtes: Since this XSLT is used for all Topic HTML_CONTENT 17 pages could implement via this XSLT (see below). Issue with XSLT 18 is that this overrides the default behavior of the HTML_CONTENT 19 processing so specific OTHER_HEAD_CONTENT and HTML_CLASS can't be 20 used as it's all or nothing without adding additional complexity. 21 So left in the XML files for now for maximum flexibility. 22 23 GARTH TODO: If lois wants all pages to scroll then implement XSLT version... 24 This is currently done via each XML file including: 25 HTML_CLASS]Topic[/HTML_CLASS] 26 [OTHER_HEAD_CONTENT] 27 [link ibis:href="css/Topic.css" rel="stylesheet" type="text/css"/] 28 [/OTHER_HEAD_CONTENT] 29 30 or can be done in XSLT like: 31 [xsl:param name="Page.htmlClass" select="'Topic'"/] 32 [xsl:template name="Page.specificCSS"] 33 [link rel="stylesheet" type="text/css" href="{$ibis.baseRequestPath}css/Topic.css"/] 34 [/xsl:template] 17 35 </description> 18 36 </ibis:doc> -
trunk/ibisph-view/src/main/webapp/xslt/json/LeafletMap.xslt
r19890 r19927 56 56 <xsl:param name="mapTitle" select="'Request JSON'"/> 57 57 <xsl:param name="mapType" select="'selection'"/> 58 <!-- GARTH TODO: maybe rename webappContextPath to match JS IF changing JS var name???? --> 58 59 <xsl:param name="webappContextPath" select="$ibis.baseRequestPath"/> 59 60 <xsl:param name="selectionLayerSetLayerKeys"/>
Note: See TracChangeset
for help on using the changeset viewer.