Appliances are standalone components that are intended to be presented at a certain mount-point in your applications. For example, a “pages” appliance might be mounted at “/pages” or “/” even.
Appliances are created using a semi-declarative controller-like class, in the same groove as frameworks such as Pylons. Many instances of a single appliance may be presented at different mount-points.
Appliance instances are callables, and the call is the equivalent of a bundle call. So for all intents, we can considfer an appliance to be just a specialised bundle. And therefore they are loaded using the application’s add_setup method. This is easy to understand, and consistent with the remainder of the glashammer framework.
Although appliances are standalone, they can be loosely coupled using Glashammer’s event framework.
Appliances are subclasses of the glashammer.utils.Appliance class, and their views are exposed using the function decorator glashammer.utils.expose:
from glashammer.utils import Response, Appliance, expose
class Pages(Appliance):
@expose('/')
def index(self, req):
return Response('index')
@expose('/edit/<int:page_id>')
def edit(self, req, page_id):
return Response('view %' % page_id)
You will note that the path given to the expose decorator is a Werkzeug Rule path. The paths are relative paths to the appliance instance’s mountpoint_path attribute. This can be set on instantiation, or using Glashammer’s configuration:
from glashammer.application import make_app
pages = Pages('/pages')
app = make_app(pages)
And we now have a wsgi application with our Pages appliance and its two views. In reality, you would not add only a single appliance as your application, you would be more likely to use:
from glashammer.application import make_app
def setup_app(app):
app.add_setup(Pages('/pages1'))
app.add_setup(Pages('/pages2'))
app = make_app(setup_app)
Here we have two appliances in our application, both serving at different paths.