Permalink
Browse files

manual merge of #52, thanks krmr

  • Loading branch information...
1 parent 1722f76 commit d1c83adb22e40cb10cd137a599552a8f91d00785 @mdipierro mdipierro committed Apr 6, 2013
Showing with 20 additions and 18 deletions.
  1. +6 −6 sources/29-web2py-english/03.markmin
  2. +14 −12 sources/29-web2py-english/04.markmin
@@ -25,7 +25,7 @@ web2py.exe
On Windows (source web2py distribution), run:
``
-c:/Python27/python.exe web2py.exe
+c:/Python27/python.exe web2py.py
``:code
------
@@ -714,8 +714,8 @@ db(db.image.id==...).select().first()
The "download" action expects a filename in ``request.args(0)``, builds a path to the location where that file is supposed to be, and sends it back to the client. If the file is too large, it streams the file without incurring any memory overhead.
Notice the following statements:
-- Line 8 creates an insert form SQLFORM for the ``db.post`` table using only the specified fields.
-- Line 7 sets the default value for the reference field, which is not part of the input form because it is not in the list of fields specified above.
+- Line 7 creates an insert form SQLFORM for the ``db.post`` table using only the specified fields.
+- Line 8 sets the value for the reference field, which is not part of the input form because it is not in the list of fields specified above.
- Line 9 processes the submitted form (the submitted form variables are in ``request.vars``) within the current session (the session is used to prevent double submissions, and to enforce navigation). If the submitted form variables are validated, the new comment is inserted in the ``db.post`` table; otherwise the form is modified to include error messages (for example, if the author's email address is invalid). This is all done in line 9!.
- Line 10 is only executed if the form is accepted, after the record is inserted into the database table. ``response.flash`` is a web2py variable that is displayed in the views and used to notify the visitor that something happened.
- Line 11 selects all comments that reference the current image.
@@ -1137,7 +1137,7 @@ If you look at the page source you see the HTML returned by the callback:
Generating an RSS feed of your wiki pages using web2py is easy because web2py includes ``gluon.contrib.rss2``. Just append the following action to the default controller:
``
def news():
- """generates rss feed form the wiki pages"""
+ """generates rss feed from the wiki pages"""
response.generic_patterns = ['.rss']
pages = db().select(db.page.ALL, orderby=db.page.title)
return dict(
@@ -1616,7 +1616,7 @@ For each application installed you can use the ''site'' page to:
All the functionality available from the web2py admin site page is also accessible programmatically via the API defined in the module ``gluon/admin.py``. Simply open a python shell and import this module.
-------
-If the Google App Engine SDK is installer the admin ''site'' page shows a button to push your applications to GAE. If ``python-git`` is installed, there is also a button to push your application to Open Shift. To install applications on ``Heroku`` or other hosting system you should look into the "scripts" folder for the appropriate script.
+If the Google App Engine SDK is installed the admin ''site'' page shows a button to push your applications to GAE. If ``python-git`` is installed, there is also a button to push your application to Open Shift. To install applications on ``Heroku`` or other hosting system you should look into the "scripts" folder for the appropriate script.
#### About
``about``:inxx ``license``:inxx
@@ -1749,7 +1749,7 @@ In order to use this feature, you must have the Mercurial version control librar
easy_install mercurial
``:code
-The Mercurial web interface does allow you to browse previous commit and diff files but we do recommend you use Mercurial directly from the shell or one of the many GUI-based Mercurial clients since they are more powerful. For example they will allow you sync your app with a remote source repository:
+The Mercurial web interface does allow you to browse previous commit and diff files but we do recommend you use Mercurial directly from the shell or one of the many GUI-based Mercurial clients since they are more powerful. For example they will allow you sync your app with a remote source repository.
@@ -967,6 +967,7 @@ Also notice the ``request.env.wsgi_*`` variables. They are specific to the wsgi
``response.menu``:inxx
``response.postprocessing``:inxx
``response.render``:inxx
+``response.static_version``:inxx
``response.status``:inxx
``response.stream``:inxx
``response.subtitle``:inxx
@@ -987,10 +988,10 @@ Also notice the ``request.env.wsgi_*`` variables. They are specific to the wsgi
- ``response.body``: a ``StringIO`` object into which web2py writes the output page body. NEVER CHANGE THIS VARIABLE.
- ``response.cookies``: similar to ``request.cookies``, but while the latter contains the cookies sent from the client to the server, the former contains cookies sent by the server to the client. The session cookie is handled automatically.
- ``response.download(request, db)``: a method used to implement the controller function that allows downloading of uploaded files. ``request.download`` expects the last ``arg`` in ``request.args`` to be the encoded filename (i.e., the filename generated at upload time and stored in the upload field). It extracts the upload field name and table name as well as the original filename from the encoded filename. ``response.download`` takes two optional arguments: ``chunk_size`` sets the size in bytes for chunked streaming (defaults to 64K), and ``attachments`` determines whether the downloaded file should be treated as an attachment or not (default to ``True``). Note, ``response.download`` is specifically for downloading files associated with ``db`` upload fields. Use ``response.stream`` (see below) for other types of file downloads and streaming. Also, note that it is not necessary to use ``response.download`` to access files uploaded to the /static folder -- static files can (and generally should) be accessed directly via URL (e.g., /app/static/files/myfile.pdf).
-- ``response.files``: a list of ``.css``, ``.js``, ``coffee``, and ``.less`` files required by the page. They will automatically be linked in the head of the standard "layout.html" via the included "web2py_ajax.html". To include a new CSS, JS, COFFEE, or LESS file, just append it to this list. It will handle duplicates. The order is important.
+- ``response.files``: a list of ``.css``, ``.js``, ``.coffee``, and ``.less`` files required by the page. They will automatically be linked in the head of the standard "layout.html" via the included "web2py_ajax.html". To include a new CSS, JS, COFFEE, or LESS file, just append it to this list. It will handle duplicates. The order is important.
- ``response.include_files()`` generates html head tags to include all ``response.files`` (used in "views/web2py_ajax.html").
- ``response.flash``: optional parameter that may be included in the views. Normally used to notify the user about something that happened.
-- ``response.headers``: a ``dict`` for HTTP response headers. Web2py sets some headers by default, including "Content-Length", "Content-Type", and "X-Powered-By" (set equal to web2py). Web2py also sets the "Cache-Control", "Expires", and "Pragma" headers to prevent client-side caching, except for static file requests, for which client-side caching is enabled. The headers that web2py sets can be overwritten or removed, and new headers can be added (e.g., ``response.headers['Cache-Control'] = 'private'``). You can remove a header by removing its key from the response.headers dict, e.g.``del response.headers['Custom-Header']``, however web2py's default headers will be re-added just before returning the response. To avoid this behavior, just set the header value to None, e.g. to remove the default Content-Type header, ``response.headers['Content-Type'] = None``
+- ``response.headers``: a ``dict`` for HTTP response headers. Web2py sets some headers by default, including "Content-Length", "Content-Type", and "X-Powered-By" (set equal to web2py). Web2py also sets the "Cache-Control", "Expires", and "Pragma" headers to prevent client-side caching, except for static file requests, for which client-side caching is enabled. The headers that web2py sets can be overwritten or removed, and new headers can be added (e.g., ``response.headers['Cache-Control'] = 'private'``). You can remove a header by removing its key from the response.headers dict, e.g. ``del response.headers['Custom-Header']``, however web2py's default headers will be re-added just before returning the response. To avoid this behavior, just set the header value to None, e.g. to remove the default Content-Type header, ``response.headers['Content-Type'] = None``
- ``response.menu``: optional parameter that may be included in the views, normally used to pass a navigation menu tree to the view. It can be rendered by the MENU helper.
- ``response.meta``: a Storage object that contains optional ``<meta>`` information like ``response.meta.author``, ``.description``, and/or ``.keywords``. The content of each meta variable is automatically placed in the proper ``META`` tag by the code in "views/web2py_ajax.html", which is included by default in "views/layout.html".
- ``response.include_meta()`` generates a string that includes all ``response.meta`` headers serialized (used in "views/web2py_ajax.html").
@@ -1000,6 +1001,7 @@ Also notice the ``request.env.wsgi_*`` variables. They are specific to the wsgi
- ``response.session_file_name``: name of the file where the session will be saved.
- ``response.session_id``: the id of the current session. It is determined automatically. NEVER CHANGE THIS VARIABLE.
- ``response.session_id_name``: the name of the session cookie for this application. NEVER CHANGE THIS VARIABLE.
+- ``response.static_version``: a version number for the static asset management.
- ``response.status``: the HTTP status code integer to be passed to the response. Default is 200 (OK).
- ``response.stream(file, chunk_size, request=request, attachment=False, filename=None, headers=None)``: when a controller returns it, web2py streams the file content back to the client in blocks of size ``chunk_size``. The ``request`` parameter is required to use the chunk start in the HTTP header. ``file`` should be a file path (for backward compatibility, it can also be an open file object, but this is not recommended). As noted above, ``response.download`` should be used to retrieve files stored via an upload field. ``response.stream`` can be used in other cases, such as returning a temporary file or StringIO object created by the controller. If ``attachment`` is True, the Content-Disposition header will be set to "attachment", and if ``filename`` is also provided, it will be added to the Content-Disposition header as well (but only when ``attachment`` is True). If not already included in ``response.headers``, the following response headers will be set automatically: Content-Type, Content-Length, Cache-Control, Pragma, and Last-Modified (the latter three are set to allow browser caching of the file). To override any of these automatic header settings, simply set them in ``response.headers`` before calling ``response.stream``.
- ``response.subtitle``: optional parameter that may be included in the views. It should contain the subtitle of the page.
@@ -1010,8 +1012,8 @@ Also notice the ``request.env.wsgi_*`` variables. They are specific to the wsgi
``
response._caller = lambda f: f()
``
-- ``response.optimize_css``: it can be set to "concat,minify,inline" to concatenate, minify and inline the CSS files included by web2py.
-- ``response.optimize_js``: it can be set to "concat,minify,inline" to concatenate, minify and inline the JavaScript files included by web2py.
+- ``response.optimize_css``: can be set to "concat,minify,inline" to concatenate, minify and inline the CSS files included by web2py.
+- ``response.optimize_js``: can be set to "concat,minify,inline" to concatenate, minify and inline the JavaScript files included by web2py.
- ``response.view``: the name of the view template that must render the page. This is set by default to:
``
"%s/%s.%s" % (request.controller, request.function, request.extension)
@@ -1125,7 +1127,7 @@ In the "generic.html" view this is done using ``{{=response.toolbar()}}``.
#### Separate sessions
-If you are storing sessions on the filesystem and you have lots of them, the file system access may become a bottle-neck. One solution is the following:
+If you are storing sessions on system access may become a bottle-neck. One solution is the followingthe filesystem and you have lots of them, the file system access may become a bottle-neck. One solution is the following:
``
session.connect(request, response, separate=True)
``:code
@@ -1367,13 +1369,13 @@ It is also possible to specify application, controller and function using named
URL(a='a', c='c', f='f')
``:code
-If the application name a is missing the current app is assumed.
+If the application name ''a'' is missing the current app is assumed.
``
URL('c', 'f')
``:code
-If the controller name is missing, the current one is assumed.
+If the controller name ''c'' is missing, the current one is assumed.
``
URL('f')
@@ -1755,7 +1757,7 @@ For example:
where ``[0]`` is an item index in symbols tuple.
``T("blabla %s %s %%{word[1]}", (var1, var2))``
-PS is used for "word" and var2 respectively.
+PS is used for "word" and "var2" respectively.
You can use several ``%%{}`` placeholders with one index:
@@ -2607,7 +2609,7 @@ Here is a more complex complete example:
def task_add(a,b):
return a+b
-secheduler = Scheduler(db, tasks=dict(demo1=task_add))
+scheduler = Scheduler(db, tasks=dict(demo1=task_add))
scheduler.queue_task('demo1', pvars=dict(a=1,b=2),
repeats = 0, period = 180)
@@ -2621,7 +2623,7 @@ A call to ``scheduler.queue_task`` returns the task ``id`` and ``uuid`` of the t
<Row {'errors': {}, 'id': 1, 'uuid': '08e6433a-cf07-4cea-a4cb-01f16ae5f414'}>
``
-If there are errors (usually syntax errors or input validation errors),
+If there are errors (usually syntax error or input validation errors),
you get the result of the validation, and id and uuid will be None
``
@@ -2648,8 +2650,8 @@ In any case, the stdout is captured and also logged into the run record.
Using appadmin, one can check all ``RUNNING`` tasks, the output of ``COMPLETED`` tasks, the error of ``FAILED`` tasks, etc.
-The scheduler also creates one more table called "scheduler_worker", which stores the workers' heartbeat and their status.
-
+The scheduler also creates one more table called "scheduler_worker", which st\
+ores the workers' heartbeat and their status.
##### Managing processes

0 comments on commit d1c83ad

Please sign in to comment.