On Thursday, August 9, 2012 8:29:48 AM UTC-4, Alexey wrote: > > > On Wednesday, August 8, 2012 4:58:27 PM UTC+2, Farski wrote: >> >> Just out of curiosity, do you have any examples of multiple extensions >> where those other than the root extension aren't a compression or archive >> format? I ask in the context of this being considered a bad practice. To >> me, naming something anImage.jpg.zip.tar.gz means I started with a JPEG, >> and then stuck that inside a zip, then put the zip in a tar, then the tar >> in a gzip. Those "extra" extensions are all container formats, so it makes >> sense to show that there's a file of a different format nested inside them. >> If things become more arbitrary, say anImage.jpg.txt, which just returns >> the JPEG's binary data as text/plain, that doesn't really hold up for me. >> That seems presentational, not a text file containing a jpeg. >> >> If the only time that multiple extensions ever come into play is >> archive/compression, middleware still seems like a good option. The URL >> helpers could remain fairly consistent (eg, resource_path(@resource, >> :format => [:xml, :zip]) and the additional functionality be transparent. >> Rails really doesn't need to know it's happening as long as it's generating >> correct URLs. If zipping is far and away the most likely case for this >> (which I think is likely), resource_path(@resource, :zipped => :xml) may >> even make sense. >> >> Basically, for all the examples I've thought of, anytime multiple >> extensions are being used appropriately, the root extension is the only one >> that it makes sense to Rails to actually handle. But if there are examples >> to indicate otherwise I'd be interested to hear them. >> >> The only things I've gotten close on is like: >> /runs/1 => web view of a GPS recorded running route >> /runs/1.json => JSON version >> /runs/1.xml => XML version >> /runs/1.xml.gpx => XML that adheres to GPX standard >> /runs/1.xml.tcx => XML that adheres to TCX standard >> But those last two, to me, are simply improperly name. >> > > I agree that it looks like a good solution to make middleware execute such > straightforward tasks as compression, and only extend Rails URL helpers. I > am not sure i would be able to do something about this myself, looks like > more work than just changing the parsing rules. > > All examples of double extensions i can think of would be of the following > two types: > > 1. a file foo.ext1.ext2 after some processing allows to recover the file > foo.ext1. > Examples: foo.csv.zip, foo.tar.gz, foo.css.sass, foo.html.erb > > 2. the first extension is a custom one, and the second is a "legal" one. > Examples: foo.source.txt, foo.miminized.js >
I have no problem with the way double extensions are used for template engines in rails. It also makes a lot of sense, and since it really isn't exposed publicly I think even though it represents things a little different than archiving and compression (index.html.erb isn't really an HTML inside an ERB wrapper), it holds up. Just like the requester for a .csv.zip knows what to expect, the requester (rails) of a .html.haml knows what to expect. As far as your second set of examples, in foo.minimized.js, the ".minimized" part isn't really an extension; it's just part of the file name. If someone named their vCard 'John.Smith.vcf', Smith isn't an extension, they just happened to use a period in the file name. So I don't think those examples really apply. ".minimized" is just convention, it could just as easily have been "foo-minimized.js" since the mine type or format is remaining the same. Anyway, I think if we really only have these two strong cases for multiple extensions, handling them case-by-case will be fine, and middleware seems like the best option for zip/etc. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/kP4dHiaPzzIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
