As you thought, when conditional arguments are not given in the requested URL,
your function's parameters will be None.

Now, it's time to see the methods parameter of route()

HTTP methods

HTTP knows different methods for accessing URLs. By default, a route only answers
to GET and POST requests, but that can be changed by providing the methods argument
to the route() decorator. For example:

which is quite handy instead of remembering all the rules and manually writing
the links.

Static files

Quite often, you will need to link static contents (images, CSS, JavaScript)
into your application. You would create a folder called static in your package
or next to your module and it will be available at /static on the application.

To generate URLs for static files, use the special static first argument:

url('static','js/common.js')

that will point to the file in static/js/common.js

– But maybe I can write directly /static/js/common.js instead of using
url() function?

Obviously, you can. However, weppy provides some useful features for static
files URLs, like languages and versioning, which are automatically applied based
on your application configuration. You can find more information in the Routing
chapter of the documentation.

Rendering the output

Now that you've discovered how weppy core works, let's find out how to render
our content. We will see how to generate an HTML response with a template and
how to generate a JSON response.

The templating system

weppy provides the same templating system of web2py, which means that you can
use Python code directly into your HTML files. Let's see it with an example.
We can make a new application with this structure:

– wait, the message I've put in the template is the returned value from my
echo() function?
– you got it!

The dictionary returned by your functions is the context of the template,
in which you can insert the values defined in Python code.
In addition, since everything you write inside {{ }} brackets is evaluated
as normal Python code you can easily generate HTML with conditions and cycles:

As you can see the only difference between the weppy template and a pure Python
code is that you have to write pass after the statements to tell weppy where
the Python block ends – normally we have indentation under Python, but we can't
have it under HTML.

The templating system has many more features: explore them in the Templates
chapter of the documentation.

Other rendering options

Quite often, you will need to render output from your functions in formats other
than HTML, such as JSON.

As you can see Pipe provide methods to run your code before the request is processed by your function (with the open method) and after your function were executed, providing different methods depending on what happened on your function: if an exception is occurred weppy will call the on_pipe_failure method, otherwise the on_pipe_success method. The close method is always called after every request has been processed, after the response has been created and before sending it to the client.

To register your pipe to a function you just need to write:

@app.route("/url",pipeline=[MyPipe()])deff():#code

And if you need to register your pipe to all your application functions, you
can omit the pipe from the route() decorator writing instead:

app.pipeline=[MyPipe()]

weppy also provides an Injector pipe, which is designed to add helping methods to the templates. Explore the Pipeline chapter of the documentation for more informations.

Redirects and errors

Taking again the example given for the request.params, we can add a redirect
on the missing URL param:

As you can see weppy applications can handle specific actions on HTTP errors.
For more information, check out the Error handling chapter of the documentation.

Sessions

An essential feature for a web application is the ability to store specific informations about the client between multiple requests. Accordingly, weppy provides another object besides the request, called session.

Session contents can be stored in several ways, such as using file or redis. In this quick start, we will see how to use the session and store its contents directly in the cookies of the client.

We're going to use the SessionManager class provided by weppy, and write a very simple route which interacts with the session:

The above code is quite simple: the app increments the counter every time the user visits the page and return this number to the user. Basically, you can store a value to the user session and retrieve it whenever the session is kept.

– and what if I try to access an attribute not existent in session?
– same as request.params: the attribute will be None and you don't have
to catch any exception

More information about storing systems is available in the Session chapter of the documentation.

Creating forms

You will probably need to build forms for your web application often. weppy
provides the Form class to help you doing that.

As you can see, the Form class accepts a list of fields for the input, and you
can add validation to your fields. The Form class comes with many options. For
example, you can set an onvalidation method to run additional validation besides
the fields' requirements.

You can also customize the form rendering and styling, or generate forms from
database tables created with the integrated ORM. Check out the Forms
chapter of the documentation and the weppy BS3 extension which
adds the Bootstrap 3 style to your forms.

Languages and translation

weppy provides an powerful, integrated multi-language system, based on web2py's,
which helps you to write applications supporting different languages.
But how does it work?

As you can see, weppy provides a language translator with the T object.
So what you should do with languages? You can just write your translation in a
file within your application called languages/it.py. That's "it" for Italian.

{"Hello, my dear!":"Ciao, mio caro!"}

The "hello" message will be translated when the user requests the Italian
language.

On default settings, the user's requested language is determined by the
"Accept-Language" field in the HTTP header, but the translation system has
another way to behave, in fact if we put this line in the prior example:

app.language_force_on_url=True

weppy uses the URL to determine the language instead of the HTTP "Accept-Language"
header. This means that weppy will automatically add the support for language on
your routing rules.

To see more about languages and dive into translator features, read the complete
documentation available in the Languages chapter.

Go ahead

Congratulations! You've read everything you need to run a simple but functional
weppy application. Use this quick-start guide as your manual, and refer to the complete documentation for every in-depth aspect you may encounter.