Method to add script tag with in-file javascript code

[martin@…]

While it is possible to add script tags for external javascript file using the add_script function in trac.web.chrome, it isn't possible to add script tags with in-file javascript code content.

While using only external javascript files is a good web design approach, some plug-ins might need to add small dynamic generated javascript code into the generated XHTML, e.g. to set variables which value depends on trac.ini settings or external sources. I had this problem recently with the ​GoogleMapMacro.

Because script tags shoudn't refer to an external file and have code content, I would like to suggest a new python method and template tag:

trac/templates/layout.html

@@ -22 +22 @@
     </py:if>
     <script py:for="script in chrome.scripts"
             type="${script.type}" src="${script.href}"></script>
+    <script py:for="script in chrome.scriptscontent" type="${script.type}">
+        /*<![CDATA[*/
+        ${script.content}
+        /*]]>*/
+    </script>
     ${Markup('&lt;!--[if lt IE 7]&gt;')}
     <script type="text/javascript" src="${chrome.htdocs_location}js/ie_pre7_hacks.js"></script>
     ${Markup('&lt;![endif]--&gt;')}

Trac-0.11.1-py2.5.egg

@@ -106 +106 @@
     req.chrome.setdefault('scripts', []).append(script)
     scriptset.add(filename)
 
+def add_script_content(req, content, mimetype='text/javascript'):
+    """Add in-file javascript code to the template.
+
+    """
+    import hashlib
+    m = hashlib.md5()
+    m.update(content)
+    digest = m.hexdigest()
+
+    scriptcontentset = req.chrome.setdefault('scriptcontentset', set())
+    if digest in scriptcontentset:
+        return False # Already added that code
+
+    scriptcontent = {'content': content, 'type': mimetype}
+
+    req.chrome.setdefault('scriptscontent', []).append(scriptcontent)
+    scriptcontentset.add(digest)
+
 def add_javascript(req, filename):
     """Deprecated: use `add_script()` instead."""
     add_script(req, filename, mimetype='text/javascript')

[Christian Boos]

e.g. to set variables which value depends on trac.ini settings or external sources

Couldn't that be done by sending a request?

[Christian Boos]

Heading to a wontfix…

[martin@…]

Replying to cboos:

e.g. to set variables which value depends on trac.ini settings or external sources

Couldn't that be done by sending a request?

Yes it could be handled using a request, but this would add an extra unneeded step. It would be a little silly if a script tag can be added but not inline code which is also valid XHTML.

[Christian Boos]

Ok, admitting we allow adding inline js code like you suggested, isn't md5 computation a bit overkill? Simply adding the code itself in a set would be enough.

[Christian Boos]

Simply adding the code itself in a set would be enough.

And we might want to do the same for warnings, as I've noticed we can get multiple times the same warning.

[Christian Boos]

Patch is more or less OK, will tweak according to comment:4 and apply.

[Remy Blank]

Updated patch for trunk.

[Remy Blank]

7775-add-inline-script-r10417.patch​ is an update for current trunk, and the duplicate elimination is much simpler (even using a set() is overkill, as there will only ever be a handful of items at most).

But isn't this superseded by add_script_data()? It allows adding JavaScript data from Python, which was the original request. I vote "wontfix" (or "worksforme").

[Christian Boos]

This add_inline_script() could still be theoretically useful for triggering some immediate action on page load ($(document).ready(...)). Maybe we could just defer the ticket until someone has a real use for this?

[Remy Blank]

I don't mind. My thought was that any code triggered on page load would almost always be the same, and only the data would change. In that case, the code should be in the template or a separate .js, and the data can be passed with add_script_data().

[Christian Boos]

Replying to rblank:

… In that case, the code should be in the template

Not easily possible for plugins, unless they write a template stream filter, which seems overkill for that.

or a separate .js,

and I was not sure what the timing would be for a $(document).ready(...) snippet present in a secondary .js file… well, I suppose it's going to be the same (the document as a whole must be ready…).

So OK for wontfix.