<momolog>
I'd like to know, whether it is possible, to write a filter, that works on binary as well as textual items.
<momolog>
It looks like a nanoc filter can only be of type :binary OR :text
<darix>
momolog: move filter code in method/class.
<darix>
call that code from your binary and text filter
<darix>
also keep in mind that binary and text filter work slightly differently
<darix>
e.g output to variable vs output to file.
<momolog>
darix: ok, that means 2 filters with shared code, right
<ddfreyne>
momolog: Yeah, it's no tpossible
<ddfreyne>
momolog: There is a github issue for that though
<ddfreyne>
momolog: I'll try to tackle it for nanoc 4.0
<ddfreyne>
momolog: what do you need it for? gzip?
<momolog>
darix / ddfreyne: thanks for your answer, you made me realize, that i do not need it at all. was trying to make nanoc-cachebuster work for text assets and images.
<momolog>
but the filter proper is only needed for html / text items pointing to the assets
<momolog>
darix / ddfreyne: the routing has to be fingerprinted for the binary items as well, but that is not a filter. i was being silly
<momolog>
works beautifully now
<momolog>
btw. fingerprinting would be a nice thing to have integrated into core nanoc
<momolog>
basically you cannot have fast (cached) and at the same time changeable websites without it
FunkyPenguin has quit [Ping timeout: 260 seconds]
FunkyPenguin has joined #nanoc
yogsototh has quit [Remote host closed the connection]
<ddfreyne>
momolog: nanoc-cachebuster has some drawbacks (e.g. it doesn}t work if the stylesheets are split over multiple files for instance)
<momolog>
ddfreyne: what do you mean? doesn't it filter all html output for references to asset files and replaces them with the fingerprinted versions?
<ddfreyne>
momolog: yeah, but it doesn’t take dependencies into account when generating the fingerprint
<momolog>
ddfreyne: ah, you mean like sass-includes?
<ddfreyne>
yes
yogsototh1 has quit [Ping timeout: 255 seconds]
pavelkunc1 has quit [Ping timeout: 257 seconds]
<guardian>
yeah I'm all against nanoc-cachebuster being merged
<guardian>
it's just one way of doing thing
<guardian>
it's not bad per se, but it's not semantically correct
<guardian>
the correct solution is to route based on compiled content :) the deadly chicken end problem
<momolog>
guardian: can you quickly elaborate on the "deadly chicken end problem"
<guardian>
momolog: you want to hash the compiled content, that is the end result of CSS that comes out of the sass filter.
<guardian>
momolog: that means everything that comes from your own scss/sass partials, and also what you imports from bourbon or compass etc
<guardian>
momolog: and ideally you want to insert that hash into the item path so that you create main.<insert hash here>.css
<momolog>
guardian: right
<guardian>
momolog: but nanoc needs to know the path before deciding if it needs to recompile an item
<guardian>
momolog: so the path needs to be known up front, but but but you also want it to depend on the compiled content, ideally
<guardian>
momolog: another solution might be, let nanoc compile main.css, but in your default layout you link to main.<hash or date>.css — and then you have an apache or nginx rewrite rule that removes the hash
<momolog>
guardian: thanks, i will meditate over this