Use CHUNKS instead of an inline tpl

[Mark-H]

I often have uses working with extra this snippet.. issues with output filters and the like, and I think many of them are caused by the fact we're forced to use an inline template. MODX parses recursively so I'm going to guess that whenever an output filter is used, the entire placeholder is REMOVED, and FileDownload R cannot access it. I've had the same issue with the Login snippet for example, but at least that one offers the possibility to use a chunk.

Using chunks will fix issues like these. Keep it as an option if you worry about backwards compatibility.

[goldsky]

hmm... you just remind me my ajax parsing problem.

anyway, in what way do you need an output filter in here?

[Mark-H]

I'm passing the [[+link]] property to a JS function to popup a "listen" box that will play the chosen mp3. But I needed to urlencode the link to properly pass it through. Ended up fixing it by urlencoding it in the js function itself, but an output filter would've saved me 15 mins figuring out how to get around this :)

[goldsky]

and what did stop you to create chunk? it'll check the database first.

[Mark-H]

I can't pass a chunk name to FileDownloadLink can I?

This is what the docs say (and because of that I didn't bother looking into the code either):

The template for this snippet is a plain href link with FileDownloadLink's placeholders, not a chunk or a template file.

[Mark-H]

If you're suggesting to put this:

[[!FileDownloadLink? &getFile=`[[+file]]` &tplCode=`[[$mytpl]]`]]

that'll have the same effect and I encourage you to read this article on how nested tags are processed: http://www.markhamstra.com/modx-blog/2011/11/nested-caching-in-modx-revolution/

[goldsky]

wowww... that's a hell of the trick!

[goldsky]

you can upgrade to rc2, now the parser has been refactor, and you can use @BINDINGs , or just the chunk's name. https://github.com/goldsky/FileDownload-R/commit/bbdc040c879c7a2bd6ba7cae268bd8f8262e1c5e#L5R440