Bryan a écrit :
I think I see what you mean
Err...
-- correct me if I'm wrong:
You are, sorry !-)
You want to
keep complex application data structures around between requests.
Nope. I want to keep all my settings parsed, my librairies loaded, all
my connections opened etc. That is, all the time consuming stuff at app
startup - which, with PHP, mostly happens for each and every request.
PHP frameworks generally allow and encourage application code
to be independent of the underlying plumbing.
This is debatable at best. PHP code (except cli PHP code of course) is
written without any care for persistent global state, concurrency
issues, race conditions etc - because it's written with the idea that
the code serving a request will be runned in total isolation. CGI
heritage here, obviously.
No, that's good web-app structure, regardless of language and server
interface. If we keep persistent global state in a shared database
rather than program variables,
Err... Did you really read what you're answering too ???
Also, I never said this execution model was necessarily bad - just that
it had pros *and* cons.
And please note I'm not criticizing this
design- just pointing one of it's consequences.
Many large,
sophisticated, high-volume web apps are in PHP.
Did anyone pretend otherwise ?
How about this howler: "The PHP execution model (mostly based on CGI
FWIW) tends to be a bit unpractical for non-trivial applications".
"tends to be a bit unpractical" != "doesn't work".
Many large, sopĥisticated etc applications are written in C. Does that
make C a practical application programming language ?
Now I'm sorry to say that for quite a few "sophisticated" PHP apps I've
seen (and eventually had to work on), the "startup" part - parsing the
include files, configuration, establishing connections etc - took a good
part of the total processing time.
--
http://mail.python.org/mailman/listinfo/python-list
