or maybe something like “try_first”
will it test files and directories or only files? would not want it to
be try_file if it tests for dirs too 
i can see the need to test for
both files and dirs.
On Thu, Dec 11, 2008 at 12:44 PM, Jean-Philippe M.
Hi Igor,
Igor S. wrote:
The new directive
- tests file(s) existence,
- and uses first found file as URI.
I want to find a name to express these actions.
If there’s an implied
then I think it would be good to have some reference to the fallback
functionality, even if it’s optional, as explicit names are more clear,
and for people trying to read documentation, directive names with
‘hidden’ functionality are hard to find.
The ‘uri’ bit, on the other hand, can be assumed, as we know from the
fact that we’re in a location block that this directive is dealing with
a particular URI, so we need to express what this directive does to
fulfil the request for that URI.
So I’d like to suggest something like ‘try_files_with_fallback’ - it’s
perhaps a bit wordy, but seems to express more clearly what’s happening.
Cheers,
Igor C.
On Fri, Dec 12, 2008 at 12:13 AM, Igor S. [email protected] wrote:
In Unix a directory is a file
ah, I guess I was just making sure, since there is -d -e and -f checks.
The new directive
- tests file(s) existence,
- and uses first found file as URI.
Yes, I understand.
I want to find a name to express these actions.
Yup, I’m trying to help find a name too, that’s one of the reasons I
asked about dirs vs. files and not limiting it to “file”
Maybe something like “first_uri” ?
On Fri, Dec 12, 2008 at 10:50:21AM +0100, Igor C. wrote:
If there’s an implied
- falls back to a named location if no file is found
then I think it would be good to have some reference to the fallback
functionality, even if it’s optional, as explicit names are more clear,
and for people trying to read documentation, directive names with
‘hidden’ functionality are hard to find.
Yes, however, fallback is not optional. The directive has at least two
parameters: the last one will be always fallback and it may be
@named_location or /uri/that/should/not/fail.
The ‘uri’ bit, on the other hand, can be assumed, as we know from the
fact that we’re in a location block that this directive is dealing with
a particular URI, so we need to express what this directive does to
fulfil the request for that URI.So I’d like to suggest something like ‘try_files_with_fallback’ - it’s
perhaps a bit wordy, but seems to express more clearly what’s happening.
I think fallback should not be mentioned.
On Fri, Dec 12, 2008 at 04:05:34PM +0100, Igor C. wrote:
‘hidden’ functionality are hard to find.
fulfil the request for that URI.
use_* is good because it makes it clear that one of the options /will/
be used; try_* is good because it makes it clear that the arguments are
tried in turn until one /can/ be used. *_file is perhaps less good
because it implies only files can be used in the list.Maybe use_resource or try_resource? I’d probably go for use_resource,
otherwise, out of the existing proposed names, I’d vote for use_file.
It should be certainly _file to indicate that a real files are tested.
How about try_to_use_file(s) ?
Igor S. wrote:
On Fri, Dec 12, 2008 at 10:50:21AM +0100, Igor C. wrote:
If there’s an implied
- falls back to a named location if no file is found
then I think it would be good to have some reference to the fallback
functionality, even if it’s optional, as explicit names are more clear,
and for people trying to read documentation, directive names with
‘hidden’ functionality are hard to find.Yes, however, fallback is not optional. The directive has at least two
parameters: the last one will be always fallback and it may be
@named_location or /uri/that/should/not/fail.
Ah, OK.
The ‘uri’ bit, on the other hand, can be assumed, as we know from the
fact that we’re in a location block that this directive is dealing with
a particular URI, so we need to express what this directive does to
fulfil the request for that URI.So I’d like to suggest something like ‘try_files_with_fallback’ - it’s
perhaps a bit wordy, but seems to express more clearly what’s happening.I think fallback should not be mentioned.
Yes, I think you’re right, because it’s one of a list of options being
tried, and in a sense it’s not actually a fallback, it’s just the last
option.
use_* is good because it makes it clear that one of the options /will/
be used; try_* is good because it makes it clear that the arguments are
tried in turn until one /can/ be used. *_file is perhaps less good
because it implies only files can be used in the list.
Maybe use_resource or try_resource? I’d probably go for use_resource,
otherwise, out of the existing proposed names, I’d vote for use_file.
Cheers,
Igor C.
Igor S. wrote:
On Fri, Dec 12, 2008 at 10:50:21AM +0100, Igor C. wrote:
Hi Igor,
Igor S. wrote:
The new directive
- tests file(s) existence,
tests file(s) existence = valid uri
- and uses first found file as URI.
uses first found file as URI = first valid uri
What about first_valid_uri ?
M.
Taking a hint from javacript how about:
try_these $uri $uri/index.html $uri.html @mongrel;
Or maybe try_these_files
Cheers-
Ezra Z.
[email protected]
Igor S. wrote:
On Fri, Dec 12, 2008 at 04:05:34PM +0100, Igor C. wrote:
It should be certainly _file to indicate that a real files are tested.
I’m happy to accept your decision on that 
How about try_to_use_file(s) ?
Seems a bit too much, maybe?
On reflection I think try_files is fine. I like Ezra’s try_these too,
either would work.
Cheers
Igor C.
My suggestion is:
select_uri_file with the default selection being the last file listed
and first file that exists is used.
Having just read the entire conversation and coming perhaps a bit too
late
in the game, I would also like to champion a try_* identifier and I
really
like the try_these identifier for an extremely general facility that
tries
each file, /uri/that/works, or even http://backends in whatever order I
specify. I would stay away from the test* family of directives unless
we
are going to add some kind of testing facility outside of if.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs