{{extend 'layout.html'}}
It is a software engineering design that separates your code for the data representation (model), data presentation (view) and application logic (controller)
Try it. You would not trust me any other way.
I will just say that while all these systems are designed for developing web applciations, Gluon is a web applications itself, the competitors are not (except Zope). Moreover Gluon is the only one that allows you to distribute byte-code compiled versions of your applications and the only one to provide a ticketing system to report errors.
Edit a controller default.py and type in it:
def hello: return dict(message="Hello")
message here is a user defined variables that is being passed to the view.
Gluon is not an AJAX framework but it works with AJAX frameworks. For examples scriptaculous works great with Gluon. You may also use Gluon controllers to handle JSON request/response messages.
Yes. Views can extend and import other views in a tree like structure. The root of the tree is what we call a layout view. It is just an HTML file that you can edit as any other view using the administrative interface.
You just overwrite filed. None of your apps, including the administrative interface and the examples will be updated. If you want to update those. Unzip the new version and move your applicaitons from oldgluon/applications/ to newgluon/applicaitons.
Use request.vars.your_variable both for GET and POST. If you try a variable that is not there, you get None, you do not get an Exception.
Use request.get_vars.your_variable
Use request.post_vars.your_variable
It should return a dictionary containing a definition of those variables you want to pass to the view. By default a function() in controller.py will be renederd by a view called controller/function.html. If this view is not found the generic.html view renders the variables in the dictionary.
A controller function can also return a string. In this case the view is not exected and the string is returned instead.
If you really must, yes, but the database administration part of the administrative interface will not work with it and the automatic generation of forms and tables will not work. You will miss about 50% of what Gluon does for you. The Gluon ORM was written from scratch in order to provide that functionality.
Yes and you should in a production environment! There are two ways. The easy way: install mod_proxy and send all your requests to the Gluon web server. You would put something like this in your /etc/apache2/sites-available/default:
NameVirtualHost *:80 <VirtualHost *:80> <Location "/"> Order deny,allow Allow from all ProxyPass http://127.0.0.1:8000/ ProxyPassReverse http://127.0.0.1:8000/ </Location> LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog /var/log/apache2/access.log common </VirtualHost>
or you can use mod_swgi. Gluon is wsgi compliant. This requires that you use the source version of Gluon and you read the mod_wsgi documentation.
You can deploy multiple installations of Gluon behind a NAT server that provides load balancing. The applications/ folder has to be NFS mounted and you need to backup that as well as your database. Do not use sqllite but connect to a postgresql database. Your bottleneck will be the database, as with any other web application. To avoid complications turn the administrative interface OFF when in production (do not give it a password) and set migrate=False.