Rails core - Aug 2012 - Feature request: allow formats with dot in resourceful routing, like '/users.xml.zip'

Hello,

would it be ok to allow formats with a dot in routing requests, like 
"`http://example.com/users.xml.zip`"?

If i am not mistaken, in this situation rails is only trying to match
"zip"
for format.  I doubt many people are using such routes now because the 
controller part is not correctly recognized and the route is not matched 
automatically at all, so this change should not break many applications.

I can think about a PR if i have time, i would appreciate an indication 
which source file to look at.

I understand that formats with a dot may have other issues, but i do not 
think they are serious:

```ruby
respond_to do |format|
  format.public_send(:''xml.zip'') { render
:''xml.zip'' => @users}
end
```

What do you think?

- Alexey Muranov.

-- 
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/-/e2wEpsceyPgJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

What about using a routing constraint for allowing the entire file extension?

E.g.  match "/download/:filename", :to =>
"downloads#download", :constraints => { :filename => /.+/ }


On Aug 4, 2012, at 11:33 AM, Alexey <alexey.muranov@gmail.com> wrote:
> Hello,
> 
> would it be ok to allow formats with a dot in routing requests, like
"`http://example.com/users.xml.zip`"?
> 
> If i am not mistaken, in this situation rails is only trying to match
"zip" for format.  I doubt many people are using such routes now
because the controller part is not correctly recognized and the route is not
matched automatically at all, so this change should not break many applications.
> 
> I can think about a PR if i have time, i would appreciate an indication
which source file to look at.
> 
> I understand that formats with a dot may have other issues, but i do not
think they are serious:
> 
> ```ruby
> respond_to do |format|
>   format.public_send(:''xml.zip'') { render
:''xml.zip'' => @users}
> end
> ```
> 
> What do you think?
> 
> - Alexey Muranov.
> 
> -- 
> 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/-/e2wEpsceyPgJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Saturday, August 4, 2012 7:42:39 PM UTC+2, Ben Mills
wrote:
>
> What about using a routing constraint for allowing the entire file 
> extension?
>
> E.g.  match "/download/:filename", :to =>
"downloads#download",
> :constraints => { :filename => /.+/ }
>
I haven''t tried this, but i see no reason it should be a separate
route. If
ressources :users
already match /users, /users.html, /users.xml, etc., why not to allow it 
match /users.xml.zip as well? 

- Alexey.

-- 
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/-/2OZJ1_ljmbEJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Also, there are request parameters, like sorting and filtering parameters, 
which are common to all formats, so i would like all formats and downloads 
to be processed by the same controller action.

- Alexey.

-- 
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/-/-ttQAFSi7NQJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I''m having a hard time thinking of use cases for this outside of zip or
other archive/compression formats. In the case of user/1.xml.zip, likely
you''d want an existing users_controller#show that returns xml to
continue to operate as it currently does, but you''d want the result to
be zipped. If there aren''t lot (any?) of other situations where stack
formatting is used, perhaps this would be better handled outside the scope of
rails; let it keep doing what it''s doing and maybe check the request
URL for compression in rack on the way in and do the compression on the way out.
If there are more general uses of this, it''s still unlikely that
you''d want a single controller action to handle both creating the xml
and zipping it if necessary.


On Aug 4, 2012, at 1:56 PM, Alexey <alexey.muranov@gmail.com> wrote:
> Also, there are request parameters, like sorting and filtering parameters,
which are common to all formats, so i would like all formats and downloads to be
processed by the same controller action.
> 
> - Alexey.
> 
> -- 
> 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/-/-ttQAFSi7NQJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Saturday, August 4, 2012 8:09:16 PM UTC+2, Farski
wrote:
>
> I''m having a hard time thinking of use cases for this outside of
zip or
> other archive/compression formats. In the case of user/1.xml.zip, likely 
> you''d want an existing users_controller#show that returns xml to
continue
> to operate as it currently does, but you''d want the result to be
zipped. If
> there aren''t lot (any?) of other situations where stack formatting
is used,
> perhaps this would be better handled outside the scope of rails; let it 
> keep doing what it''s doing and maybe check the request URL for
compression
> in rack on the way in and do the compression on the way out. If there are 
> more general uses of this, it''s still unlikely that you''d
want a single
> controller action to handle both creating the xml and zipping it if 
> necessary. 
>
Maybe "csv.zip" or "pdf.zip" make better sense.
I can of course define formats "csv_zip" and "pdf_zip" and
use them, but i
would prefer "csv.zip" and "pdf.zip".

- Alexey.

-- 
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/-/nvcKZqSESFAJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

You can already do something like this: 

In your routes:

  get "foo(.:format)(.:compression)" => "foo#index"


Then in your controller:

    respond_to do |format|
      format.xml do
        if params[:compression] == "zip"
          render ...
        else
          render ...
        end
      end
    end



That being said a format of csv.zip is not `csv` since it is zipped and it is
not purely `zip` since that gives no indication of the actual contents of the
file. Having some kind of built in support for this would be expected by me if I
was trying this out for the first time.

Though if we were to add this feature I would expect it to be greedy so if you
visit `foo.csv.zip` it would first look for a `csv.zip` format and if that was
not found, it would look for a `csv` format as a backup. I haven''t
checked into the implementation implications. If it is simple to implement with
no performance impact I would be :+1: otherwise it''s not enough of a
win as you can already do something like this (as above).

If someone implements this cc/ me on the PR and I''ll be happy to
comment.

-- 
Richard Schneeman
http://heroku.com

@schneems (http://twitter.com/schneems)




On Saturday, August 4, 2012 at 1:24 PM, Alexey wrote:
> On Saturday, August 4, 2012 8:09:16 PM UTC+2, Farski wrote:
> > I''m having a hard time thinking of use cases for this outside
of zip or other archive/compression formats. In the case of user/1.xml.zip,
likely you''d want an existing users_controller#show that returns xml to
continue to operate as it currently does, but you''d want the result to
be zipped. If there aren''t lot (any?) of other situations where stack
formatting is used, perhaps this would be better handled outside the scope of
rails; let it keep doing what it''s doing and maybe check the request
URL for compression in rack on the way in and do the compression on the way out.
If there are more general uses of this, it''s still unlikely that
you''d want a single controller action to handle both creating the xml
and zipping it if necessary.
> > 
> 
> 
> Maybe "csv.zip" or "pdf.zip" make better sense.
> I can of course define formats "csv_zip" and "pdf_zip"
and use them, but i would prefer "csv.zip" and "pdf.zip".
> 
> - Alexey. 
> 
> -- 
> 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/-/nvcKZqSESFAJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

There''s a tension here between content types and
''format'' too. A
foo.csv.zip would have a Content-Type of application/zip, so having a
format of ''csv'' (which has a type of text/csv) is a little
strange.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I see no better way to name this format than ''csv.zip''  (with
Content-Type
''application/zip'').

-- 
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/-/l1IhoVdtF4wJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 04/08/2012, at 15:54, Alexey <alexey.muranov@gmail.com> wrote:
> I see no better way to name this format than ''csv.zip'' 
(with Content-Type ''application/zip'').
But then you''d have ''csv.zip'',
''xml.zip'', etc be application/zip.

If you want to support both in a controller action, what happens when someone
requests /users with Accept application/zip? Which one wins?

The .format notation is just a workaround for things that can''t
add/change the Accept header to the request (like HTML links), but it''s
just a workaround.

Cheers,
-foca
> -- 
> 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/-/l1IhoVdtF4wJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Sure, but the ''txt.zip'' would also have a type of
application/zip.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Saturday, August 4, 2012 9:24:28 PM UTC+2, Nicolás Sanguinetti
wrote:
>
>
> But then you''d have ''csv.zip'',
''xml.zip'', etc be application/zip.
>
> If you want to support both in a controller action, what happens when 
> someone requests /users with Accept application/zip? Which one wins?
>
> The .format notation is just a workaround for things that can''t
add/change
> the Accept header to the request (like HTML links), but it''s just
a
> workaround.
>
> Cheers,
> -foca
>
I know nothing about Accept header.  Since it needs a workaround, i prefer 
not to rely on it too much.  I see no problem that all
''txt.zip'',
''xml.zip'', ''csv.zip'' have the same
Content-Type.  This means they all
should be accepted if Accept header is application/zip, the one with the 
correct ''format'' should be rendered.

- Alexey.

-- 
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/-/qOPinbS5ZiwJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

If the goal of this post is to change the functionality of `:format` to 
return "xml.zip", then I disagree.  "xml.zip" is not a file
extension,
which I believe the `:format` param is intended to represent.  Looking at 
the list of file
formats<http://en.wikipedia.org/wiki/List_of_file_formats_(alphabetical)>,
it is not on the list -- only "zip" is because it is still a zip file 
despite the "xml" preceding it.

This is the same as saying that "tar.gz" is a file extension --
it''s not.
 The "tar" before the "gz" indicates that this gzipped file
probably
contains a tar file, but the extension is still "gz".  That''s
probably why
the "tgz" file format was introduced.

Just my 2 cents.

On Saturday, August 4, 2012 1:33:44 PM UTC-4, Alexey
wrote:
>
> Hello,
>
> would it be ok to allow formats with a dot in routing requests, like
"`
> http://example.com/users.xml.zip`
<http://example.com/users.xml.zip>"?
>
> If i am not mistaken, in this situation rails is only trying to match 
> "zip" for format.  I doubt many people are using such routes now
because
> the controller part is not correctly recognized and the route is not 
> matched automatically at all, so this change should not break many 
> applications.
>
> I can think about a PR if i have time, i would appreciate an indication 
> which source file to look at.
>
> I understand that formats with a dot may have other issues, but i do not 
> think they are serious:
>
> ```ruby
> respond_to do |format|
>   format.public_send(:''xml.zip'') { render
:''xml.zip'' => @users}
> end
> ```
>
> What do you think?
>
> - Alexey Muranov.
>
-- 
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/-/yos64d2w_JgJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Sunday, August 5, 2012 4:51:37 PM UTC+2, Matt Huggins
wrote:
>
> If the goal of this post is to change the functionality of `:format` to 
> return "xml.zip", then I disagree.  "xml.zip" is not a
file extension,
> which I believe the `:format` param is intended to represent.  Looking at 
> the list of file
formats<http://en.wikipedia.org/wiki/List_of_file_formats_(alphabetical)>,
> it is not on the list -- only "zip" is because it is still a zip
file
> despite the "xml" preceding it.
>
> This is the same as saying that "tar.gz" is a file extension --
it''s not.
>  The "tar" before the "gz" indicates that this gzipped
file probably
> contains a tar file, but the extension is still "gz". 
That''s probably why
> the "tgz" file format was introduced.
>
> Just my 2 cents.
>
Matt, i was only proposing to parse the URL slightly differently, probably 
without impact for existing applications.  I am already using both
"csv"
and "csv.zip" formats in my application (mostly for testing and 
experimenting), i only do not like that i have to access "csv.zip"
like
this: "/users.csv_zip".

- Alexey.

-- 
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/-/xDIinV1UBLAJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Monday, August 6, 2012 1:02:49 PM UTC+2, Alexey
wrote:
>
> Matt, i was only proposing to parse the URL slightly differently, probably 
> without impact for existing applications.  I am already using both
"csv"
> and "csv.zip" formats in my application (mostly for testing and 
> experimenting), i only do not like that i have to access
"csv.zip" like
> this: "/users.csv_zip".
>
I meant, parsing resourceful routes by default.  I know i can define routes 
with my own parsing rules by hand.

- Alexey. 

-- 
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/-/K3CB4mYmpOQJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Of all the suggestions thus far I think the one that makes the most sense 
is a Rack middleware (or even further out on Apache/Nginx/etc).  That 
watches for the request to expect compressed results and does the 
compression removing the extension on the way in and re-applying it on the 
way out.  Not involving Rails at all.

Note that there is a module for nginx that (may) solve this already:  
http://wiki.nginx.org/NgxZip   (I haven''t used it at all, it probably 
doesn''t do any form of url re-writing to handle the .zip extension as 
necessitated to make this Rails transparent)


On Monday, 6 August 2012 07:02:49 UTC-4, Alexey wrote:
>
> On Sunday, August 5, 2012 4:51:37 PM UTC+2, Matt Huggins wrote:
>>
>> If the goal of this post is to change the functionality of `:format` to
>> return "xml.zip", then I disagree.  "xml.zip" is
not a file extension,
>> which I believe the `:format` param is intended to represent.  Looking
at
>> the list of file
formats<http://en.wikipedia.org/wiki/List_of_file_formats_(alphabetical)>,
>> it is not on the list -- only "zip" is because it is still a
zip file
>> despite the "xml" preceding it.
>>
>> This is the same as saying that "tar.gz" is a file extension
-- it''s not.
>>  The "tar" before the "gz" indicates that this
gzipped file probably
>> contains a tar file, but the extension is still "gz". 
That''s probably why
>> the "tgz" file format was introduced.
>>
>> Just my 2 cents.
>>
>
> Matt, i was only proposing to parse the URL slightly differently, probably 
> without impact for existing applications.  I am already using both
"csv"
> and "csv.zip" formats in my application (mostly for testing and 
> experimenting), i only do not like that i have to access
"csv.zip" like
> this: "/users.csv_zip".
>
> - Alexey.
>
-- 
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/-/fQXCFVzbOFYJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> Of all the suggestions thus far I think the one that makes the most sense
is
> a Rack middleware (or even further out on Apache/Nginx/etc).  That watches
> for the request to expect compressed results and does the compression
> removing the extension on the way in and re-applying it on the way out. 
Not
> involving Rails at all.
Yes, we call this deflate:
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
http://apidock.com/rails/Rack/Deflater/deflate/class

This thread isn''t really about zipping, it''s about multiple
extensions.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Ahaha my second link sucks. Whatever, you know what I mean. (I need to
get an email filter that requires me to drink at least one cup before
hitting send.)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Thanks for the ideas to use middleware to compress the response and to 
pre-parse the URL, but i think i would like that it be possible for the 
application to parse URLs with multiple extensions as well.

If multiple extensions are not considered a ''bad practice'' and
if they can
be used to indicate ''composite formats'', for the use by
middleware for
example, why not to allow rails to take multiple extensions into account as 
well?  Also, the views are generated by the application, so the application 
has to know anyway at which url and with which Accept header to access 
zipped CSV or PDF, to be able to generate a correct link or button element. 
 So compression cannot be viewed as just an optional middleware 
configuration independent of the applicaiton.

If multiple extensions are discouraged and i need to use Accept header, then
  a. how to set it from an html <a> element? (I''ve seen that in
HTML5 there
is the "type" attribute, but i''ve read "it is purely
advisory", does it
work?)
  b. URL does not anymore determine the response completely, which i do not 
like.
  c. requesting /users.csv with Accept header application/zip looks to me 
either strange or no better than requesting /users.csv.zip directly.


-- 
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/-/3_SmtqcKsVcJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.



On Tuesday, August 7, 2012 6:57:19 AM UTC-4, Alexey
wrote:
>
> Thanks for the ideas to use middleware to compress the response and to 
> pre-parse the URL, but i think i would like that it be possible for the 
> application to parse URLs with multiple extensions as well.
>
> If multiple extensions are not considered a ''bad
practice'' and if they can
> be used to indicate ''composite formats'', for the use by
middleware for
> example, why not to allow rails to take multiple extensions into account as
> well?  Also, the views are generated by the application, so the application
> has to know anyway at which url and with which Accept header to access 
> zipped CSV or PDF, to be able to generate a correct link or button element.
>  So compression cannot be viewed as just an optional middleware 
> configuration independent of the applicaiton.
>
> If multiple extensions are discouraged and i need to use Accept header, 
> then
>   a. how to set it from an html <a> element? (I''ve seen that
in HTML5
> there is the "type" attribute, but i''ve read "it is
purely advisory", does
> it work?)
>   b. URL does not anymore determine the response completely, which i do 
> not like.
>   c. requesting /users.csv with Accept header application/zip looks to me 
> either strange or no better than requesting /users.csv.zip directly.
>
>
>
-- 
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/-/z2PakEoKgjcJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.



On Tuesday, August 7, 2012 6:57:19 AM UTC-4, Alexey wrote:
Thanks for the ideas to use middleware to compress the response and to pre-parse
the URL, but i think i would like that it be possible for the application to
parse URLs with multiple extensions as well.

If multiple extensions are not considered a ''bad practice'' and
if they can be used to indicate ''composite formats'', for the
use by middleware for example, why not to allow rails to take multiple
extensions into account as well?  Also, the views are generated by the
application, so the application has to know anyway at which url and with which
Accept header to access zipped CSV or PDF, to be able to generate a correct link
or button element.  So compression cannot be viewed as just an optional
middleware configuration independent of the applicaiton.

If multiple extensions are discouraged and i need to use Accept header, then
  a. how to set it from an html <a> element? (I''ve seen that in
HTML5 there is the "type" attribute, but i''ve read "it
is purely advisory", does it work?)
  b. URL does not anymore determine the response completely, which i do not
like.
  c. requesting /users.csv with Accept header application/zip looks to me either
strange or no better than requesting /users.csv.zip directly.


-- 
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/-/z2PakEoKgjcJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

-- 
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/-/_B_uIfTcdYQJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Thursday, August 9, 2012 6:51:30 PM UTC+2, Farski
wrote:
>
>
> 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.
>
If a ressource is named  "foo_minimized.js", according to rails
conventions
for resourceful URLs, it would need to be processed by the controller 
"foo_minimized", a different one than for  "foo.js".

-- 
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/-/X3AM0Is307gJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Here is another example of how i personally sometimes use double 
extensions, this is a particular case of the first category i described 
above: i may add a more specific extension after a less specific, like in

    notes.txt.md

This is in case i will ever send the file to someone who does not know 
about Markdown.

I remind that this thread in my opinion is about parsing resourceful URLs.

-- 
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/-/yjH8kNtqJ4MJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.