Wes,
thank you for sharing. I wish I had more time to answer, because there are tons of interesting things here!

Processing tokens anywhere, and not only in modules instancing the current token-replace engine, is what I think we are addressing here. I recently had the opportunity to work on a WordPress project, and I could appreciate its smart tags system: I don't have a deep knwowledge of the architecture, but they are available (almost) anywhere and I like this.
But that's a different system, so let's talk about something useful to us. Hopefully ;)

I understand the performance problem... yet replacing tokens only when the full page is ready to be rendered appears to be the only possibility, if we want to process tokens anywhere. We could improve the token-replace engine (which btw already allows you to add custom tokens if I remember well), but a real win would only to find a way not to modify existing modules, and let tokens be processed anyway and anywhere.
BTW does your implementation present serious performance issues? That site where you process tokens anywhere, in containers also (yes I'm asking! ;)) is performing so bad? Do you use data-caching apis to improve performances?

If performance is a problem there, why don't we try to do this in another way?
I'm thinking about processing tokens in another moment, and not when HTML is ready for rendering. For example at the data-provider level: could we ask the SqlDataProvider to process tokens on content data it gets from the database, before it gives data back to the controller?
A problem is we don't know if tokens are to be processed on all data, just to begin with. Module controller should be able to enable or disable token-replace... what about a new ITokenReplace interface to be optionally implemented, like we do for ISearchable and IPortable for example, at module level?

Yes this is not "tokens anywhere" and would mean modifying our modules, but would this kind of approach improve performance? Or is it just a stupid idea?

Regards,

al.

One thing we did find that gave us a lot of performance improvements was to mask out the session cache variable before starting our replaces = basically = copy then remove the session cache variable from the stringbuilder - do all our macro replaces and then put the session cache variable back in.  On pages that made extensive use of global macros this represented a large Improvement in performance.

The other area which is problematic is ajax and client site rendering - modules that do a lot of client side rendering - say like the journal module - wont work with this sort system - since they are not rendering their CONTENT as part of the asp.net lifecycle - instead the content is being rendered on the HTML browser side based on data returned from AJAX requests.

Westa

The dnn sharp tool is worth a look ... But may not do exactly what you are expecting in some cases ... Exactly how it works is for its owners to discuss ... But there is patching the core and patching modules in its skill set ... Out of the box it is able to patch known core modules and utilise hooks that developers have added to their commercial modules.

Patching modules it regards as different to patching the core ...   Patching the core usually involves a change to the dnn .dll library's .... Patching a module on the other hand can be achieved by make changes to a module itself.

From what I know about their module however it is still ... Module level replace based ... Pit can't do a global replace at the page /skin level without a skin object being added to the skin 

westa