Chris Angelico <ros...@gmail.com> writes: > On Thu, Oct 12, 2017 at 9:44 AM, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: >> Chris Angelico <ros...@gmail.com> writes: >>> Check out Django and Flask, the two most popular ways. I quite like >>> Flask. >> >> I see. Both appear to be frameworks (I'd heard of Django). Do you know >> if they widely available on low-cost hosting packages? (I don't think >> they are on mine, but that's dirt-cheap because I don't use it for >> anything important!) > > Generally, low-cost hosting will offer Python, and then you can > install Flask/Django from there. For example, you can deploy to Heroku > (zero-dollar hosting for small sites), and as long as you provide a > file called "requirements.txt", they'll install whatever you depend > on. > >> One thing that helped PHP was that it could be used (and learned) in an >> incremental way. You could add a "this page last updated on..." text in >> a line or two to an existing page. Then a button to change the layout >> or theme. Then a simple form and so on. >> >> Many professionals started that way. In the early days, there ware few >> other routes into the technical side of web authoring. That helped to >> cement PHP as the dominant technology because it was what they knew. > > Yeah. The trouble is that this is a really REALLY bad way to design > something.
Yes, I know that's the way of the devil, just I'm explaining why PHP is popular! > Have you seen a city that grew one house at a time, and had > streets added to service those houses? Not good. The end result is > that PHP is still bound by this "just a bit of scripting inside your > HTML" structure, which has annoying consequences in certain areas > (like whitespace before the first "<?" being significant in certain > situations, and the way "include" works), plus it binds your URLs to > the concrete file system. That may not seem like too much of a > problem, but it's a pretty big limitation; you can't have URLs like > "https://en.wikipedia.org/wiki/Foo"; without some help from the web > server, eg Apache's mod_rewrite. I don't follow this. Your "can't" and "big limitation" suggests something inevitable, but I don't see it as an intrinsic problem with the language. I'm sure PHP is not as flexible as the frameworks you mention, but you are not tied to URLs mapping to files. Maybe you meant that this is what often happens, or what most people do, with PHP. > In contrast, Python and Flask would > handle that like this: > > @app.route("/wiki/<article>") > def show_article(article): > ... > > Have a think about what the PHP setup implies. Arbitrary files in your > web server tree are not just automatically available (as they'd be if > you use flat-file hosting like GitHub Pages), but they are > *executable*. You don't have to set the file mode to say "this is > executable", you just have to have the file there with the appropriate > name. So PHP-based web sites end up having to monitor their uploads > and downloads lest someone slip something in and then run it on the > server... with full permissions. With Flask, in contrast, you can make > an uploads directory that's automatically downloadable, but nothing in > it will ever be executed. Yes, it's fraught with security issues. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
