On 21 May 2011 17:34, Stuart Dallas <stu...@3ft9.com> wrote:
> On Sat, May 21, 2011 at 4:24 PM, Peter Lind <peter.e.l...@gmail.com> wrote:
>> On 21 May 2011 17:18, Stuart Dallas <stu...@3ft9.com> wrote:
>> *snip*
>> >> Again, this depends upon what your url scheme looks like - and without
>> >> knowing that, there's simple no clue as to whether or not this is a
>> >> good solution to the problem (though it might be a good solution to A
>> >> problem).
>> >
>> > Again, I disagree. If you have an example of a URL structure where this
>> > would not work I'd love to hear it.
>> > -Stuart
>> Having to replace several times just in order to figure out the path
>> to your script is pointless if you know the name of the script (which
>> you always do - it's __FILE__ ) and you're using a one-to-one
>> request-to-script scheme. Then just grab the part of the url up to and
>> including your scriptname.
> Well, it would be basename(__FILE__), but that's beside the point. In this
> particular case, where the PHP filename is the last part of the URL, that
> will indeed work. However, as you have pointed out several times that's not
> always the case and I tend to write generic, defensive code rather than make
> assumptions.

Not a bad habit. I would personally go with "let's either find out or
make a decision" instead of wasting time on coding for situations that
will crop up.

>> Note I used the word good - doing several str_replace() and other
>> calls is not what I consider a good solution if there's something
>> simpler available with as good a result.
> Obviously that's your choice to make, but these days I very rarely work on
> projects where there is a one-to-one mapping, and even if I did I would not
> rely on that always being the case. I've worked on a number of projects
> where the URL structure has been massively changed (a couple from one-to-one
> to controller-based) where it would have taking an excessive amount of time
> to undo that assumption.
> Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> future-proof and takes no more effort than the manipulation you are doing on
> __FILE__ to get the same result. Given the choice I'll always go for 10%
> extra work now to save 90% extra work later, even if it's only potential
> work later.

I can generally agree with that, depending on project though.


WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to