Elliotte Harold wrote:
David Krings wrote:
Elliotte Harold wrote:
Edward Potter wrote:
hmmmm, I have never found this to be a problem. Using includes, you
can pull in .php code from anywhere, even pages with a .php extension
may be 99.99% html, with a just a single include('foo.php') in it.
Keeps things super streamlined, and your pages are very readable.
You've got it backwards. I want one script to service many URLs, not
many scripts to service one URL.
And that is exactly how Edward described it. You include the one
script into the many URLs you want to make use of the script.
I guess that isn't what you are after, it just reads that way.
What you are proposing is not one script to service N URLs. It is N+1
scripts to service N URLs. It is still necessary to create N separate
loader scripts and place them at the right locations. That doesn't
scale, and it's an extraordinary waste of resources when a small
percentage of the possible URLs will ever be reached.
I sincerely apologize for helping out. I am convinced that my proposal
would be a suitable solution (you need one script, not more), but
apparently confusion and misunderstanding takes precedence. If I could
I'd eradicate my posts to save you from the disgust that I must have
generated. In any case, I am deeply sorry to have caused you discomfort.
Overall, though, I suspect all parties (Apache, PHP, Tomcat, Rails. etc.) are
still too mired in circa-1994 models of web servers serving file systems. For
example, once you map /foo to a servlet you can't then map /foo/bar to
something else.
Well, then use IIS and ASP if that is a better solution. As you pointed
out, these are "circa-1994" models that apparently work very well in
2007. So much so that almost 2/3 of all internet sites use exactly this
technology. Those folks must all be idiots for using something that so
obviously doesn't work! There isn't much technology around that was
created in the 90s and that still works well for today's needs. I don't
see the big deal if a web server mirrors a file system structure, the
problem is on how to get to the desired file - which can be done with an
arbiter script that gets hit on each access and then redirects to the
desired location.
Since the server just has to know what to serve up it will be quite easy
to structure the site based on unique IDs and use a database table to
retrieve the corresponding paths.
Calling mysite.gov/1234 directs to mysite.gov/foo/bar/index.php and
calling mysite.gov/4321 directs to mysite.gov/bar/foo/index.php. Of
course, you need to add that information to a table or a simple ini file
if no db is available. With a table you got one db connection, one
select query, a few lines error output in case the resource doesn't
exist, and one line for the redirect. Similar approach when using some
authentication. And for the case that each resource is supposed to use
the same code, instrument each resource with an include. I'd use two
independent script files for that, but I guess one could smush that into
one file as well. And with include I mean using the PHP code word
"include()", not copying the code into each resource. And even that
could be automated. I have written self-replicating scripts that worked
out OK unless I wanted to make changes.
I apologize upfront if my comments yet again generated an intellectual
distaste. In that case, I give up and you are on your own.
Have a nice day,
David
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
