You don’t need to understand what is in the buffer, the idea is that the interceptor that you create listens for that event or more to the point is run when it is announced.
So that means one interceptor could be for adding what you want, another could be for adding skins and another could be for adding JS to the header. All interceptors will do what they need to do, all they just have to be registered and the custom interception points registered. For example I wrote two modules for ContentBox, that uses this one sole purpose is for displaying the Open Graph tags for my blog as it is run only once it gets displayed only once, the second module has another interceptor and its sole purpose is to display Google Analytics, and I can switch them on or off without changing core code.
You could get to the buffer if you need, but in this case there will be no need. As the interceptor is only run once and will add what you tell it too add, as the example shows. To show case that create two interceptors to listen for the same announcement, but display different things.
As for the difference, the approach I have gone down is to apply that html helper only when the renderer is loaded and configured, that means it will be available in any view or viewlet only. Where DI will only make it available to the handler, so if you wanted to write your own or extended or changed version then you have the ability to do so.
As for being restrictive, it is the exact opposite.
Lets take modules into consideration here for a minute, each would not know what the other is doing. Which means you have to write code to do all sorts of checks, for example like you discovered you need a way to only include it once. You could use the addAsset method and it will do the same job, but you would need to have two parts one that adds the asset and one that actually displays the asset. The adding part will be the area where you check to see if it has already been added.
Now modules come into play, because you can drop a module in that can be notified of this interception point, and just append to the buffer nothing more nothing less, and you can just pull the module or place/drop it in and it will just work. With less code to do so.
The scalability is that bit, there is nothing more to write and you’re allowing for future modules to hook into this or not.
Well canonical links, now this is something I have read up, but only briefly over the years. But these links are for search engines, what that means is that if you have a path or in the case of ColdBox a handler that might display a table of contacts, but you could sort these depending on what criteria you pass through the event handler. Search engines don’t care about this, and they are more inclined to just use the default option or whatever the feel is best.
In other words if the data or content is going to be the same, with different options to display the content differently then search engines would like to know so they display what you want them to display when the link is clicked in the search engine.
So in your case, you can build the canonical link the same way inside the htmlHelper or the interceptor it doesn’t matter where.
And yes that was a mistake on my part with the interceptor method, I have now fixed this, as there is an issue with some posts when editing the code gets jumbled, so I had to re-paste it again and forgot to change the method name.
And thanks for the positive feedback on my blogging. As for taking it a step further, sure I can do that with another post, might be a few days though.