When it comes to combining multiple controller or view functions (however you want to call them), you need a dispatcher. A simple way would be applying regular expression tests on PATH_INFO and call registered callback functions that return the value.
Werkzeug provides a much more powerful system, similar to Routes. All the objects mentioned on this page must be imported from werkzeug.routing, not from werkzeug!
Here is a simple example which could be the URL definition for a blog:
from werkzeug.routing import Map, Rule, NotFound, RequestRedirect
url_map = Map([
Rule('/', endpoint='blog/index'),
Rule('/<int:year>/', endpoint='blog/archive'),
Rule('/<int:year>/<int:month>/', endpoint='blog/archive'),
Rule('/<int:year>/<int:month>/<int:day>/', endpoint='blog/archive'),
Rule('/<int:year>/<int:month>/<int:day>/<slug>',
endpoint='blog/show_post'),
Rule('/about', endpoint='blog/about_me'),
Rule('/feeds/', endpoint='blog/feeds'),
Rule('/feeds/<feed_name>.rss', endpoint='blog/show_feed')
])
def application(environ, start_response):
urls = url_map.bind_to_environ(environ)
try:
endpoint, args = urls.match()
except HTTPException, e:
return e(environ, start_response)
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Rule points to %r with arguments %r' % (endpoint, args)]
So what does that do? First of all we create a new Map which stores a bunch of URL rules. Then we pass it a list of Rule objects.
Each Rule object is instantiated with a string that represents a rule and an endpoint which will be the alias for what view the rule represents. Multiple rules can have the same endpoint, but should have different arguments to allow URL construction.
The format for the URL rules is straightforward, but explained in detail below.
Inside the WSGI application we bind the url_map to the current request which will return a new MapAdapter. This url_map adapter can then be used to match or build domains for the current request.
The MapAdapter.match() method can then either return a tuple in the form (endpoint, args) or raise one of the three exceptions NotFound, MethodNotAllowed, or RequestRedirect. For more details about those exceptions have a look at the documentation of the MapAdapter.match() method.
Rule strings basically are just normal URL paths with placeholders in the format <converter(arguments):name>, where converter and the arguments are optional. If no converter is defined, the default converter is used (which means string in the normal configuration).
URL rules that end with a slash are branch URLs, others are leaves. If you have strict_slashes enabled (which is the default), all branch URLs that are visited without a trailing slash will trigger a redirect to the same URL with that slash appended.
The list of converters can be extended, the default converters are explained below.
Here a list of converters that come with Werkzeug:
This converter is the default converter and accepts any string but only one path segment. Thus the string can not include a slash.
This is the default validator.
Example:
Rule('/pages/<page>'),
Rule('/<string(length=2):lang_code>')
| Parameters: |
|
|---|
Like the default UnicodeConverter, but it also matches slashes. This is useful for wikis and similar applications:
Rule('/<path:wikipage>')
Rule('/<path:wikipage>/edit')
| Parameter: | map – the Map. |
|---|
Matches one of the items provided. Items can either be Python identifiers or unicode strings:
Rule('/<any(about, help, imprint, u"class"):page_name>')
| Parameters: |
|
|---|
This converter only accepts integer values:
Rule('/page/<int:page>')
This converter does not support negative values.
| Parameters: |
|
|---|
This converter only accepts floating point values:
Rule('/probability/<float:probability>')
This converter does not support negative values.
| Parameters: |
|
|---|
Important
Werkzeug evaluates converter arguments as if they were Python method calls. Thus, you should never create rules from user-submitted data since they could insert arbitrary Python code in the parameters part.
As a matter of fact, this is a legal definition and sets fixed_digits to 2:
url_map = Map([
Rule('/picture/<int(fixed_digits=1 + 1):id>.png',
endpoint='view_image')
])
However, evaluating Python expressions is currently an implementation detail and might be unavailable in the future.
The map class stores all the URL rules and some configuration parameters. Some of the configuration values are only stored on the Map instance since those affect all rules, others are just defaults and can be overridden for each rule. Note that you have to specify all arguments besides the rules as keyword arguments!
| Parameters: |
|
|---|
New in version 0.5: sort_parameters and sort_key was added.
Add a new rule or factory to the map and bind it. Requires that the rule is not bound to another map.
| Parameter: | rulefactory – a Rule or RuleFactory |
|---|
Return a new MapAdapter with the details specified to the call. Note that script_name will default to '/' if not further specified or None. The server_name at least is a requirement because the HTTP RFC requires absolute URLs for redirects and so all redirect exceptions raised by Werkzeug will contain the full canonical URL.
If no path_info is passed to match() it will use the default path info passed to bind. While this doesn’t really make sense for manual bind calls, it’s useful if you bind a map to a WSGI environment which already contains the path info.
subdomain will default to the default_subdomain for this map if no defined. If there is no default_subdomain you cannot use the subdomain feature.
Like bind() but you can pass it an WSGI environment and it will fetch the information from that dictionary. Note that because of limitations in the protocol there is no way to get the current subdomain and real server_name from the environment. If you don’t provide it, Werkzeug will use SERVER_NAME and SERVER_PORT (or HTTP_HOST if provided) as used server_name with disabled subdomain feature.
If subdomain is None but an environment and a server name is provided it will calculate the current subdomain automatically. Example: server_name is 'example.com' and the SERVER_NAME in the wsgi environ is 'staging.dev.example.com' the calculated subdomain will be 'staging.dev'.
If the object passed as environ has an environ attribute, the value of this attribute is used instead. This allows you to pass request objects. Additionally PATH_INFO added as a default of the MapAdapter so that you don’t have to pass the path info to the match method.
Changed in version 0.5: previously this method accepted a bogus calculate_subdomain parameter that did not have any effect. It was removed because of that.
| Parameters: |
|
|---|
New in version 0.6: a dict of default converters to be used.
Iterate over all rules and check if the endpoint expects the arguments provided. This is for example useful if you have some URLs that expect a language code and others that do not and you want to wrap the builder a bit so that the current language code is automatically added if not provided but endpoints expect it.
| Parameters: |
|
|---|
Iterate over all rules or the rules of an endpoint.
| Parameter: | endpoint – if provided only the rules for that endpoint are returned. |
|---|---|
| Returns: | an iterator |
Returned by Map.bind() or Map.bind_to_environ() and does the URL matching and building based on runtime information.
Building URLs works pretty much the other way round. Instead of match you call build and pass it the endpoint and a dict of arguments for the placeholders.
The build function also accepts an argument called force_external which, if you set it to True will force external URLs. Per default external URLs (include the server name) will only be used if the target URL is on a different subdomain.
>>> m = Map([
... Rule('/', endpoint='index'),
... Rule('/downloads/', endpoint='downloads/index'),
... Rule('/downloads/<int:id>', endpoint='downloads/show')
... ])
>>> urls = m.bind("example.com", "/")
>>> urls.build("index", {})
'/'
>>> urls.build("downloads/show", {'id': 42})
'/downloads/42'
>>> urls.build("downloads/show", {'id': 42}, force_external=True)
'http://example.com/downloads/42'
Because URLs cannot contain non ASCII data you will always get bytestrings back. Non ASCII characters are urlencoded with the charset defined on the map instance.
Additional values are converted to unicode and appended to the URL as URL querystring parameters:
>>> urls.build("index", {'q': 'My Searchstring'})
'/?q=My+Searchstring'
If a rule does not exist when building a BuildError exception is raised.
The build method accepts an argument called method which allows you to specify the method you want to have an URL built for if you have different methods for the same endpoint specified.
New in version 0.6: the append_unknown parameter was added.
| Parameters: |
|
|---|
Does the complete dispatching process. view_func is called with the endpoint and a dict with the values for the view. It should look up the view function, call it, and return a response object or WSGI application. http exceptions are not caught by default so that applications can display nicer error messages by just catching them by hand. If you want to stick with the default error messages you can pass it catch_http_exceptions=True and it will catch the http exceptions.
Here a small example for the dispatch usage:
from werkzeug import Request, Response, responder
from werkzeug.routing import Map, Rule
def on_index(request):
return Response('Hello from the index')
url_map = Map([Rule('/', endpoint='index')])
views = {'index': on_index}
@responder
def application(environ, start_response):
request = Request(environ)
urls = url_map.bind_to_environ(environ)
return urls.dispatch(lambda e, v: views[e](request, **v),
catch_http_exceptions=True)
Keep in mind that this method might return exception objects, too, so use Response.force_type to get a response object.
| Parameters: |
|
|---|
The usage is simple: you just pass the match method the current path info as well as the method (which defaults to GET). The following things can then happen:
If the path info is not passed to the match method the default path info of the map is used (defaults to the root URL if not defined explicitly).
All of the exceptions raised are subclasses of HTTPException so they can be used as WSGI responses. The will all render generic error or redirect pages.
Here is a small example for matching:
>>> m = Map([
... Rule('/', endpoint='index'),
... Rule('/downloads/', endpoint='downloads/index'),
... Rule('/downloads/<int:id>', endpoint='downloads/show')
... ])
>>> urls = m.bind("example.com", "/")
>>> urls.match("/", "GET")
('index', {})
>>> urls.match("/downloads/42")
('downloads/show', {'id': 42})
And here is what happens on redirect and missing URLs:
>>> urls.match("/downloads")
Traceback (most recent call last):
...
RequestRedirect: http://example.com/downloads/
>>> urls.match("/missing")
Traceback (most recent call last):
...
NotFound: 404 Not Found
| Parameters: |
|
|---|
New in version 0.6: return_rule was added.
Test if a rule would match. Works like match but returns True if the URL matches, or False if it does not exist.
| Parameters: |
|
|---|
A Rule represents one URL pattern. There are some options for Rule that change the way it behaves and are passed to the Rule constructor. Note that besides the rule-string all arguments must be keyword arguments in order to not break the application on Werkzeug upgrades.
Rule strings basically are just normal URL paths with placeholders in the format <converter(arguments):name> where the converter and the arguments are optional. If no converter is defined the default converter is used which means string in the normal configuration.
URL rules that end with a slash are branch URLs, others are leaves. If you have strict_slashes enabled (which is the default), all branch URLs that are matched without a trailing slash will trigger a redirect to the same URL with the missing slash appended.
The converters are defined on the Map.
An optional dict with defaults for other rules with the same endpoint. This is a bit tricky but useful if you want to have unique URLs:
url_map = Map([
Rule('/all/', defaults={'page': 1}, endpoint='all_entries'),
Rule('/all/page/<int:page>', endpoint='all_entries')
])
If a user now visits http://example.com/all/page/1 he will be redirected to http://example.com/all/. If redirect_defaults is disabled on the Map instance this will only affect the URL generation.
The subdomain rule string for this rule. If not specified the rule only matches for the default_subdomain of the map. If the map is not bound to a subdomain this feature is disabled.
Can be useful if you want to have user profiles on different subdomains and all subdomains are forwarded to your application:
url_map = Map([
Rule('/', subdomain='<username>', endpoint='user/homepage'),
Rule('/stats', subdomain='<username>', endpoint='user/stats')
])
A sequence of http methods this rule applies to. If not specified, all methods are allowed. For example this can be useful if you want different endpoints for POST and GET. If methods are defined and the path matches but the method matched against is not in this list or in the list of another rule for that path the error raised is of the type MethodNotAllowed rather than NotFound. If GET is present in the list of methods and HEAD is not, HEAD is added automatically.
Changed in version 0.6.1: HEAD is now automatically added to the methods if GET is present. The reason for this is that existing code often did not work properly in servers not rewriting HEAD to GET automatically and it was not documented how HEAD should be treated. This was considered a bug in Werkzeug because of that.
If given this must be either a string or callable. In case of a callable it’s called with the url adapter that triggered the match and the values of the URL as keyword arguments and has to return the target for the redirect, otherwise it has to be a string with placeholders in rule syntax:
def foo_with_slug(adapter, id):
# ask the database for the slug for the old id. this of
# course has nothing to do with werkzeug.
return 'foo/' + Foo.get_slug_for_id(id)
url_map = Map([
Rule('/foo/<slug>', endpoint='foo'),
Rule('/some/old/url/<slug>', redirect_to='foo/<slug>'),
Rule('/other/old/url/<int:id>', redirect_to=foo_with_slug)
])
When the rule is matched the routing system will raise a RequestRedirect exception with the target for the redirect.
Keep in mind that the URL will be joined against the URL root of the script so don’t use a leading slash on the target URL unless you really mean root of that domain.
As soon as you have more complex URL setups it’s a good idea to use rule factories to avoid repetitive tasks. Some of them are builtin, others can be added by subclassing RuleFactory and overriding get_rules.
All URLs provided by this factory have the subdomain set to a specific domain. For example if you want to use the subdomain for the current language this can be a good setup:
url_map = Map([
Rule('/', endpoint='#select_language'),
Subdomain('<string(length=2):lang_code>', [
Rule('/', endpoint='index'),
Rule('/about', endpoint='about'),
Rule('/help', endpoint='help')
])
])
All the rules except for the '#select_language' endpoint will now listen on a two letter long subdomain that holds the language code for the current request.
Like Subdomain but prefixes the URL rule with a given string:
url_map = Map([
Rule('/', endpoint='index'),
Submount('/blog', [
Rule('/', endpoint='blog/index'),
Rule('/entry/<entry_slug>', endpoint='blog/show')
])
])
Now the rule 'blog/show' matches /blog/entry/<entry_slug>.
Prefixes all endpoints (which must be strings for this factory) with another string. This can be useful for sub applications:
url_map = Map([
Rule('/', endpoint='index'),
EndpointPrefix('blog/', [Submount('/blog', [
Rule('/', endpoint='index'),
Rule('/entry/<entry_slug>', endpoint='show')
])])
])
Returns copies of the rules wrapped and expands string templates in the endpoint, rule, defaults or subdomain sections.
Here a small example for such a rule template:
from werkzeug.routing import Map, Rule, RuleTemplate
resource = RuleTemplate([
Rule('/$name/', endpoint='$name.list'),
Rule('/$name/<int:id>', endpoint='$name.show')
])
url_map = Map([resource(name='user'), resource(name='page')])
When a rule template is called the keyword arguments are used to replace the placeholders in all the string parameters.
You can easily add custom converters. The only thing you have to do is to subclass BaseConverter and pass that new converter to the url_map. A converter has to provide two public methods: to_python and to_url, as well as a member that represents a regular expression. Here is a small example:
from random import randrange
from werkzeug.routing import Rule, Map, BaseConverter, ValidationError
class BooleanConverter(BaseConverter):
def __init__(self, url_map, randomify=False):
super(BooleanConverter, self).__init__(url_map)
self.randomify = randomify
self.regex = '(?:yes|no|maybe)'
def to_python(self, value):
if value == 'maybe':
if self.randomify:
return not randrange(2)
raise ValidationError()
return value == 'yes'
def to_url(self, value):
return value and 'yes' or 'no'
url_map = Map([
Rule('/vote/<bool:werkzeug_rocks>', endpoint='vote'),
Rule('/vote/<bool(randomify=True):foo>', endpoint='foo')
], converters={'bool': BooleanConverter})
If you want that converter to be the default converter, name it 'default'.


Javascript Opus Recorder
make sure you enable permissions for recording audio.
start
stop
auto-upload :
upload every( in seconds):


?0
1
cm
6
7
8
9
10
copyright
reserved
The
Newark
Botanical
Garden
HKRBARIUM,
BOTANICAL
DEPART.VIi.
NT,JA.
ÇaICA.
Locality,_
Collector,_
No._Date,
7
VO
ff
01497879
01497879
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


A CDN (Content Delivery Network) is becoming more and more commonplace in hosting plan offerings and a must for an business site. By hosting web content on servers that are spread across the globe, you can deliver content to any user faster by targeting servers that are relatively more local to them.
But if you’re like me, you are not overly technical; you get the concept of a CDN in theory, but do you GET IT get it? Here’s my nontechnical take on what a CDN is and why it’s a true benefit for any website.
Imagine we have a room.
In this room, we’re going to place a single television screen. This screen is your website. Likely, when you start out, you don’t have much of an audience.
As you begin developing content, a handful of friends and colleagues may visit. Plus, your site will begin being crawled by search engine bots.
But as you attract more attention, it gets a bit hard to gain access to your site and its content. Too many folks want to get to your site at the same time and they can’t just get close enough to the source for a quick, enjoyable experience.
Here is where a CDN could help. By storing the same content, images, and files that make up your site in several locations, you create multiple access points that allow for faster site loads.
Plus, with more servers hosting the same bits of your site, traffic can be more uniformly handled to prevent bottleneck issues.
Also, if one server location experiences and outage — either from an innocent traffic surge or a malicious DDoS attack — the redundancy of the network can ensure your site is still accessible to all.
 For those of you on WordPress, you can take advantage of JetPack’s free Photon add-on. I also have clients using CloudFlare, Akamai, and Amazon CloudFront.
These clients have seen better pageload speeds and less downtime during traffic surges by actively leveraging a CDN. Odds are your hosting provider offers their own CDN service, or has partnered with a third-party, so it is worth investigating to see if you can start benefitting from a distributed content network.


Custom Emoji, only $15
Enter your MyMoji Details
We will email you when the MyMoji is ready
What would you like us to know when making your MyMoji (optional)
Note: We can only include one person or animal in your emoji. Also, the artists work with the close-up you send, so we don't allow you to say "give me cool sunglasses." But if you want to, get some cool sunglasses and upload a new close-up, that will work.
Upload a close-up!


Liquor Store
What is your age?
Verify
Coin Flipper
Filp Coin
Rock, Paper, Scissors
Select a weapon:
Rock
Paper
Scissors
Play!