#232: Resource Registries Improvements

Conditional Comment

A small string to be included in a conditional comment around the resource. For example, entering simply 'IE' in the field will result in a conditional comment of: <!--[if IE]>...<![endif]--> 

This would be interpreted by IE as something to be processed. All other browsers would see a valid HTML comment and ignore the contents. Another option would be to target a specific version of IE using Microsoft's syntax such as "lt IE7" would only be used by browsers earlier than IE 7. This behavior is currently only enabled for the CSS Registry. For more information see: http://msdn.microsoft.com/en-us/library/ms537512.aspx

An Enhancement request in the tracker that I stumbled upon motivated me to become more proactive with the Plone community and the requests for the ability to include external resources in registries (resources not hosted by the Plone site) and have IE conditional comments around CSS resources so that, at a minimum, the IEFixes.css file no longer has to be hard-coded into main_template.

Coding is already complete and available in two branches:

• Conditional Comments
• External Resources

Patches are also available on the plone tracker:

• Conditional Comments
• External Resources

Implementation is already complete. See above.

Example cssregistry.xml entry for IEFixes.css for conditional comments:

<stylesheet title="" cacheable="False" compression="none" cookable="False"
 rel="stylesheet" expression="" id="IEFixes.css" media="all" enabled="1"
 rendering="import" conditionalcomment="IE" />

This would result in the following inclusion in a rendered page:

<!--[if IE]>       
    
      <style type="text/css" media="all">@import url(http://localhost:8080/registryTest/portal_css/Plone%20Default/IEFixes.css);</style>
    
<![endif]-->

Example jsregistry.xml entry for external jQuery library:

<javascript cacheable="False" compression="none" cookable="False"
 enabled="True" expression="" id="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"
 inline="False" insert-before="jquery-integration.js" />

This would result in the following inclusion in a rendered page:

<script type="text/javascript"
    src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js">
</script>

According to limi, we are actually encouraged to reference single sources for things like javascript as explained in http://ajaxian.com/archives/announcing-ajax-libraries-api-speed-up-your-ajax-apps-with-googles-infrastructure

 The only extra code needed at this point is an additional migration step for CMFPlone to move IEFixes.css into the registry and remove the call to it from main_template.pt

There are a few risks with introducing new functionality without clear documentation on how to use conditional comments as well as expectations of merging, caching and compression of external resoucres, which in my branches are forcefully disabled and will raise exceptions if bad values are attempted to be set.

Special Case: SSL

SSL presents an additional hurdle to a seamless user experience. Most modern browsers will throw a warning if any resources (javascript, CSS, images, etc) are included without also being retrieved via an SSL connection as well. To that end, external resources would need to be defined twice, once for normal HTTP connections, and a second for SSL connections. An example jsregistry.xml below:

<javascript cacheable="False" compression="none" cookable="False"
 enabled="True" expression="python:request.get('ACTUAL_URL','').startswith('https://')"
 id="https://jqueryjs.googlecode.com/files/jquery-1.2.6.min.js"
 inline="False" insert-before="jquery-integration.js" />

<javascript cacheable="False" compression="none" cookable="False"
 enabled="True" expression="python:request.get('ACTUAL_URL','').startswith('http://')"
 id="http://jqueryjs.googlecode.com/files/jquery-1.2.6.min.js"
 inline="False" insert-before="jquery-integration.js" />

Note that the only real difference between them is that the first tests for, and links to https, and the second, only for http. This introduces a bit of redundancy, but helps solve the problem where you can't guarantee that the url for the SSL version of an external resource is the same as the non-SSL resource except for the protocol. The major example of this is in Google Analytics.

• Code complete. It's possible that more tests are required, but I'm not sure how to write them, especially with generic setup.
  

fschulze said he would be willing to handle the merging of the two patches provided.