Symphony.

AAAAAA nickdunn you are my hero, I totally forgot that callbacks are registered in a table in the DB and not registered each time the page is loaded... (this is my .NET background haunting me!!! In .NET, pages fire events which are handles by listener and gets hooks each time a page is loaded)

Thank you so much for making my day better by not wasting my time on this !

i'm mostly putting this here just to remind myself, but as per another thread an extension to keep dynamic datasources from caching. perhaps this will evolve into a full development/production mode extension.

Would there be a big performance hit if you check the page prior to output to see if there were any {$params} to convert? Thinking about creating an extension that would convert parameters in fields (i.e. XML)...

Datasources are being overhauled for the next version (2.3) which is due out around December this year.

I don't know if it would be worth building an extension to do this yet...

I don't think data sources are being overhauled at all, more, there is consideration for a JSON data source type, and potentially additional filtering syntax. Lewis I'm not sure what you're proposing, could you elaborate?

For example, inside a textarea field with markdown:

[A link]($root/linked-page/)

Where $root would be replaced with http://example.com by the extension. I have had the desire more than once to use the core parameters in a field.

I fully support @Lewis on that ! This could be great... Perhaps a extented version of MarkDown ?

I don't think data sources are being overhauled at all

Caching is getting looked at though, and with the list of changes being discussed, I would have called it an overhaul. But that may just be me.

I reckon you should just feature request parameter replacement on text areas for the core, rather than another field.

Also on the TextBox extension.

I reckon you should just feature request parameter replacement on text areas for the core, rather than another field.

I wasn't thinking of a field extension; simple an extension that fire on front-end page load. Could be a performance issue...

I wasn't thinking of a field extension; simple an extension that fire on front-end page load. Could be a performance issue...

Best would be if Text Area and Text Box (or any other "text-formatted" field) could format text on demand and cache it. That way, there could be text-formatters that use $parameters and it would not be a big hit to performance. That would also allow for much easier format changes - without a need to re-save all fields whenever you want to change text-formatter, because cache could be cleared and fields would re-format text on demand.

Could be a ninja XSLT utility that does the replacing...

Could be a ninja XSLT utility that does the replacing...

Why didn't I think of that, damn you Nick... err, I mean thank you!!

Damn @nickdunn !! You always look at things with a different angle!

But how would you locate the curly-braces ?

But how would you locate the curly-braces ?

they can be escaped by doubling up: {{ }}. of course, with ninja technique you're not limited to symphony's parameter syntax. you could come up with something a little more markdowny for your users.

@fawx: Wow did not knew that, thanks !

One could build a new "Ninja template" with a different qname. Call the real ninja in the new one and just replace the mode value in the existing code... WOW !

I thinking about W*rdPress and it makes me laugh !!!!

I thinking about W*rdPress and it makes me laugh !!!!

Mwa ha haah, Mwah hah haaaaah haaaaaaaaa *cough cough*

If anyone is looking for the ninja template to format relative URLs, it's in utilities.

@designermonkey: hahahaha :)

@bauhouse: nice job ! Really usefull in RSS Feeds !

@Nitriques, well I can't take credit for it. But it is really useful! :-)