In PHP world you can just create index.php file, put some inline code and raw HTML, run Apache and it just works.
There are a lot af talks about bad practices of using inline code an so on. So we won't discuss this theme here, please.
How can I start my Ruby application same way? I want to use ERB for code messing, so it will look this way
# index.rb
<h1>Hello world!</h1>
<div>
1 + 1 = <%= 1 + 1 %>
</div>
So my questions are:
What makes PHP just work.
AFAIU(nderstand) There is native support for HTTP in PHP, so I have to use Rack to support it with Ruby
Some basic knowledge for creating my on "microframework": working with application/http servers (Mongrel, nginx, binding on http port and all such kind of job), working with HTTP requests: sessions, params, GET/POST etc (Rack?), sending responses (ERB templating).
So I can make my own (in educational puprposes) microframework for PHP-style web development with Ruby :D
UPD
What really I want to do is an application wich will just get request url, run just that file and return HTML as a response. Also this application should be allowed to be binded on some port
index.rb
info/about.rb
info/contacts.rb
products/product.rb
so It should parse url localhost/index.rb and run index.rb, localhost/products/product.rb?product_id=10 and run products/product.rb and pass product_id=10 as a params hash.
UPD 2
I think good point to start is to dig into Camping microframework source:
https://github.com/camping/camping
It is about 5Kb weight so I shouldn't be confused in it
It is possible to write CGI scripts with Ruby but this is generally not done because we have better solutions.
One file per page is not a very useful abstraction, it's just the one that PHP supports. Ruby has better ways to abstract a web application (like Sinatra, Rails, or even just Rack) so we prefer to use them.
Putting the file name in the url is another unfortunate side effect of PHP's design. It is implementation revealing and unnecessary (you're not getting a Ruby page, you're getting an HTML page), so we choose not to do that either.
CGI and FCGI in Ruby are also slower than the other solutions. This is not because of some limit on how performant they can be; it's mostly just because the effort to make Ruby web applications faster has been spent in more useful areas like Rack and Rails. No one really uses CGI so no one really cares to make it fast. mod_ruby makes CGI scripts somewhat faster if you really want to go this route, but again: there are better ways.
Apache can run PHP by loading in the mod_php module.
I believe to run ruby you will need to have it installed on the server and have mod_ruby loaded into apache. take a look at: http://www.modruby.net/en/
You are looking for CGI. The Apache modules like mod_php or mod_ruby are just packaging provided for CGI scripts written in PHP or Ruby.
Related
I have a C# application that needs to call a PHP script, and get the output, in the fastest possible way. The options I explored:
Executing the script with PHP CLI (Pro: Easy / Cons: No Opcode Cache / Precompilation ]
Compiling the PHP (Phalanger, Hiphop, etc.) [Pro: No Webserver / Con: Compatibility ]
Using an embedded webserver (AppWeb, Cherokee, Lighttpd) [Pro: Simple / Cons: Deployment ]
Are there any other options left?
EDIT: The best possible option would be to make use of the build-in FastCGI server of PHP, by running php-cgi.exe -b 127.0.0.1. But there seems no (C#) code to talk to a server available. While there are so many server-side libraries (like FCGIDotNet and SharpCGI), they all implement the server-side of the protocol.
One other option could be to run the PHP CLI script as a daemon (good blog post on this here).
If the script has a particularly long startup/cleanup, then running it as a daemon would mean that you only do this once.
The downside is that you'd need to write a way of communicating with that daemon, to get the data from C# to it. You'd also need to keep an eye out on its memory usage over time.
The best method is always going to be specific to your script though.
As you may know, PHP originally stood for "Personal Home Page", it is now said to stand for "PHP: Hypertext Preprocessor", which literally states it's usage, and basically is not something that a developer would embed into his application just to have a scripting option.
Unless you have some really specific piece of software and strong arguments, I'd suggest you to stick to Lua, or similar scripting libraries which are easy to embed and maintain. Otherwise, use it the way as everyone is using it, CLI. Or else be prepared to face the consequences.
I wanted to try out python to create webpages instead of using php. However I came across that you need either mod_python or mod_wsgi installed to apache to make it play with python. If you now use pure, i'm not sure if it should be said pure, python code, not using any web frameworks like django. I found out that making a simple page looks differently in mod_python and in mod_wsgi.
How come?, the more I looked into python it just seemed to be a harder language to use to make webpages comparing it to php. Is there some good starting point to learn python webdevelopment?
Sorry if my question is blurry. I simply want some guidance to start out with python webdevelopment
Yes, making a webpage with python without using a web framework is harder than it is in php. This is by design, since it gives you a great deal more control over how your page interacts with the server, allowing you to build sites that scale well, among other benefits. WSGI is the modern way to interact with a server, but as you observed, it includes many of the nuts and bolts that PHP hides from the user.
If you're looking for a php-like experience for python, you might look at web.py or Flask. They are pretty minimalistic as far as frameworks go, and take care of interacting with the server but otherwise stay out of your way.
That said, you really should consider Django or another similar framework - they provide some really great benefits that help you get what would otherwise be painfully complex sites going quickly. They solve a slightly different problem and provide different solutions from the common PHP frameworks, so you should consider them even if you don't like frameworks in PHP.
If you want to do things in an even more php-like fashion, you could use CGI. It's definitely not a recommended solution, and won't teach you best practices moving forward, but it can get you started...
Really though, consider a framework. It's how most development in Python for the web is done, and you'll learn more useful skills if you develop using one.
mod_wsgi is better, because it's based on the WSGI specification, which defines the interface between web applications (or frameworks) and web servers. A WSGI app at its simplest is nothing more than a function that sends some HTTP headers via a callback and returns a string in response to information about an HTTP request. And since WSGI is implemented by many web servers, you aren't tied to Apache.
The closest you can get to pure frameworkless web development in Python is to write the WSGI app directly. This will really help you see the things that a framework like Django will obscure.
To make things easier, you might consider using Werkzeug, which is a utility library for WSGI. It has many components that are framework-like, but you can choose which ones you want and which ones you don't. For example, it has a really neat system for parsing and dispatching URLs. Werkzeug also has a simple command-line WSGI server which is probably better for development than Apache.
I'm replying to you with some advice, as someone who was in a very similar situation as you just a few months ago.
So you're using apache to host your website. That's cool. To make python play nice with apache, you're going to want to use mod_wsgi, for the reasons others have stated: seperation of concerns makes it better than cgi and mod_python is no longer being supported.
However, your impression that foregoing a framework will bring you closer to programming in "pure" python is a little bit off the mark. I shared the same opinion, and experimented with both Django and using only mod_wsgi. Let me share what I found.
Mod_wsgi is an implementation of the WSGI standard found in PEP 333. The distinction between the implementation and the standard is important. First, because it means that WSGI compliant applications will work across implementations. More importantly, it reveals something important about what WSGI is meant to do. That is, WSGI is intended a standard for writing frameworks. From the PEP:
simplicity of implementation for a framework author is not the same thing as ease of use for a web application author
and
The goal of WSGI is to facilitate easy interconnection of existing servers and applications or frameworks, not to create a new web framework.
I'm not saying that you shouldn't do something with wsgi, but you should expect to be writing a framework more than an application. If you're interested in writing a simple framework this tutorial is where I started.
However, if you're just looking to make a website, look into one of the frameworks that others have suggested. You'll still be writing python code, but the authors have worked hard to make the code you write closer connected producing websites than producing frameworks. I've personally used Django, and once it was up and running, it was rather painless to churn out interesting applications. Also, their documentation is very good, and they have a good tutorial here. That being said, Django is very fully featured, and if you're looking for something a little more minimalistic, I've heard good things about Flask, but there are lots of other options as well.
You can use ordinary CGI, which is really simple. Create a Python program that looks something like this:
#!/usr/bin/env python
import sys
sys.stdout.write("Content-type: text/html\r\n\r\n")
print("Hello <em>world</em>!")
Make this file executable (chmod +x) and put it in a directory you've configured for CGI files in your web server.
You will also find the standard Python cgi module very helpful.
If your goal is for making your python program web friendly then the answer is Cherrypy. It is a very flexible and simple framework that enables your python objects exposed in web. Check it out and it has a nice web server built-in that you don't need apache/mod_wsgi etc.,
Basically I'm looking for a way to get rid of my PHP dependence, and I would like to switch to Python. I'm having trouble finding a way to basically make python a drop in replacement. I'm familiar with Django but its just not quick and dirty enough for most small things I have to do. So I'm wondering if there is an Apache module or a way to setup mod_wsgi to serve up *.py files the same way mod_php serves up *.php from the server root?
Note: I have found the various python extensions to php for calling code from PHP but that doesn't really solve the curly brace hell.
The files that mod_wsgi calls are Python files. Additionally, if you set them up in daemon mode, updating the python file will restart the daemon. It's pretty slick.
Another thing you could look at if Django is overkill is Werkzeug, which is pretty much just the server interface. Then later you can add database access with SqlAlchemy and/or templating with Jinja2. Or not.
These pieces are pretty much what people use when they want Django as pieces, and I'm told that they're more powerful, if more work to maintain (some assembly required).
Yes you can do that with mod_wsgi, but if you are new to developing Python web applications it is a potentially painful way to go about it. Either way, read the documentation at:
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apache_Alias_Directive
You use AddHander just like you would with CGI or PHP scripts.
if you worked with php also you are familiar to mod_php
also there is mod_python ( http://www.modpython.org/ ) but its not active community ( there is many article how set django with mod_python ( http://docs.djangoproject.com/en/dev/howto/deployment/modpython/ ) )
but its better use wsgi and uwsgi
http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
http://code.google.com/p/modwsgi/
I realize it's probably something strange, but here is what I have.
I have an application (handwriting recognition engine) written in C/C++. This application has Perl wrapper which was made by application's authors using SWIG. My website is written in PHP, so I'm looking for some ways to make PHP work with C/C++ application.
The only way I can think of now is to create a CGI script (perl script) which accepts POST request from my website (AJAX request), sends it to the recognition engine through it's Perl wrapper, gets the required data and returns the required data as a response to AJAX request.
Do you think it could be done this way? Are there any better solutions?
Thank you!
Do you think it could be done this way?
Yes, no reason it can't be done.
Are there any better solutions?
May be. If you intend to execute the perl wrapper as a system call to a separate Perl script, you don't need a separate CGI perl script. You can just do system calls from PHP in your site directly. Not a big difference but might help if PHP is more of your comfort zone for web stuff than Perl's CGI
OTOH, if the Perl script wrapper is a fairly obvious and simple set of API calls, and you feel comfortable with Perl CGI, a better soltrion is to port that command line Perl script into the Perl CGI script which uses the API internally, bypassing system calls.
For high-volume stuff, removing system calls is a Big Win performance wise, plus allows for much better and easier error handling.
What you are proposing is:
web client <-> Perl CGI script <-> Perl wrapper <-> C program
There is nothing particularly wrong with this approach, although it's clearly not the most efficient possible way to do it. How important is performance? If it's doesn't have to be amazingly fast, sure do it this way, which sounds like it's the easiest to develop.
If you want to go a step further, then the obvious point of optimization in the schematic above is to collapse the two Perl layers:
web client <-> Perl CGI script <-> C program
The question is, is it worth your time to do this? You can look at the source for the Perl wrapper and decide for yourself.
My advice would be to initially develop it the simple way and then if, for whatever reason, you decide it is insufficient, to merge the two Perl scripts into one. But for now, don't worry about it and go ahead with your idea.
Why mod_python is oop but mod_php is not ?
Example :We go to www.example.com/dir1/dir2
if you use mod_python apache opens www/dir1.py and calls dir2 method
but if you use php module apache opens www/dir1/dir2/index.php
Let's talk about mod_python vs. mod_php.
Since the Python language is NOT specifically designed for serving web pages, mod_python must do some additional work.
Since the PHP language IS specifically designed to serve web pages, mod_php simply starts a named PHP module.
In the case of mod_python (different from mod_fastcgi or mod_wsgi), the designer of mod_python decided that the best way to invoke Python is to call a method of an object defined in a module. Hopefully, that method of that object will write the headers and web page content to stdout.
In the case of mod_wsgi, the designer decided that the best way to invoke Python is to call a function (or callable object) in a module. Hopefully that function will use the supplied object to create header and return a list strings with the web page content.
In the case of mod_php, they just invoke the module because PHP modules are designed to serve web pages. The program runs and the result of that run is a page of content; usually HTML.
The reason mod_php works one way, mod_python works another and mod_wsgi works a third way is because they're different. Written by different people with different definitions of the way to produce a web page.
The php page can be object-oriented. A mod_wsgi function may be a callable object or it may be a simplef unction. Those are design choices.
The mod_python requirement for a class is a design choice made by the designer of mod_python.
The reason "why" is never useful. The reason "why" is because someone decided to design it that way.
Because mod_python is abstracting the URL into a "RPC-like" mechanism. You can achieve the same in PHP. I always did it by hand, but I am pretty sure there are prepackaged pear modules for this.
Note the mod_python behavior is not forcibly "the best". It all amounts to the type of design you want to give to your application, and how it behaves to the clients. As far as I see, the mod_python approach assumes that for every URL you have a function, like mapping the module structure into a URL tree. This is technically not a particularly nice approach, because there's a tight correlation between the technology you are using (mod_python) and the URL layout of your application.
On the reason why, theres' no reason. Some people like one food, and some other like another. Design is, in some cases, a matter of taste and artistic choices, not only technical restrains.
I think you have some misconceptions about how HTTP works. Nothing in the http standard requires you to have a certain file as a resource. It is just the way how mod_php works, that for a given path, this path is translated to a php file on the disk of the server, which in turn is interpreted by the compiler.
The mod_python module on the other hand is much more generic, it allows you to map any resource to a call to some python object. It just happens that some configurations are available out of the box, to make it easier to start with. In most cases the dispatch of the url is managed by your framework, and how that works is up to the framework implementor.
Because of the generic nature of the mod_python module you are also able to access some apache features which are not available in the mod_php module, for instance you may write your own authentication handler, which my not only apply to your python webapp, but also to other apps in your apache as well.
in PHP you can program your web pages the top-to-bottom scripts, procedural programming and function calls, OOP. this is the main reason why PHP was first created, and how it evolved. mod_php is just a module for web servers to utilize PHP as a preprocessor. so it just passes HTTP information and the PHP script to PHP interpreter.
the PHP way of web page creation is do what you want; write a top-to-bottom script, define functions in different files and include those and call functions, or write your app in OOP, you can also use many full-featured frameworks today to make sure your application design and structure meets today best practices and design patterns.
I'm new to Python, and am not familiar with web programming with python. but as much as I know, python was not created to make web programming easier. it was intended to be a general purpose programming language, so although it might be possible to write simple top-to-bottom scripts in python and run them as web page responses (I'm not sure if such thing is possible), it is not the pythonic way, and so I think developers of the mod_python wanted web programming in python to be in a pythonic way.
Perhaps I misunderstand your question, but both Python and PHP support both procedural and object-oriented programming. (Though one could argue that Python's support for OO is the stronger of the two.)
See Class and Objects in PHP 5