NYCPHP Meetup

[Paul A Houle]

Ajai Khattri wrote:
> On Mon, 30 Mar 2009, Paul A Houle wrote:
>
>   
>> My question is,  am I missing a good PHP built-in for combining parts of 
>> URLs or filesystem paths?  Is there a good library I should use?
>>     
>
> You might want to look at routing components. For example, you can use 
> symfony's routing component by itself without using the whole framework to 
> match URLs (and generate URLs I think):
>
>   
    The site I'm thinking about most at the moment has it's own routing 
framework that's got some influence from symfony,  but it's got a little 
more interaction between the "master controller" and the 
"subcontrollers" that allows it to manage it's relationship with web 
browsers,  crawlers and semweb clients.  For instance,  I can move stuff 
around in crazy ways and everything will redirect correctly.  Just 
launched it at

http://carpictures.cc/

    For a number of practical reasons,  I'm obsessive about URL 
canonicalization for this site,  so don't want to see //'s in URLs,  not 
like the //'s that GNU autoconf codes into applications when people 
aren't careful about specifying the --prefix.

    There's a lot of things I like about symfony:  overall I think the 
routing is OK for content-oriented sites,  even tolerable for webapps 
(though I sometimes like to route based on POST variables there) but 
I've got enough differences to roll my own.  The framework for that site 
is designed to enable extreme reuse of schemas,  templates and such for 
similar sorts of sites:  it's kind of a CMS built for machines instead 
of people.

    Chris and Brent had practical solutions and I'll probably built a 
simple library for path wrangling.

    Overall I don't agree w/ Dan's idea that this is a training and 
documentation issue.  Car Pictures is a pilot project for something 
that's going to be at least 100 times bigger:  it's going to involve 
getting more people in,  and controlling costs is going to be an 
important part of making the vision work.  I think it's cheaper to build 
a system that can't be screwed up than it is to (i) spend time writing 
documentation,  (ii) expect people to spend time reading it,  (iii) 
looking over people's shoulders to make sure that they read the docs and 
that they follow it,  and (iv) dealing with the downstream consequences 
of people not complying.  See

http://en.wikipedia.org/wiki/Poka-yoke
http://en.wikipedia.org/wiki/Quality_costs