How Ferris does MVC

Ferris is similar to a lot of other MVC frameworks such as Rails or CakePHP, though the terminology may be slightly different:

• Models handle the retrieval and storage of data in the App Engine Datastore. Models are simply Google App Engine ndb.Model subclasses with a few helper methods. Typically a most of the business logic is implemented in the model layer. This encourages code-reuse and make it easier to test all of your business logic.
• Controllers are responsible for responding to HTTP requests. Controllers are typically thin glue between models and views. Controllers have special methods called actions that are accessable via HTTP.
• Views handle the presentation of data to the user. Views have access to data that is retrieved by the controller. Views can render HTML, JSON, or other representations.
• Routing maps urls to controller actions. This happens automatically, but Ferris allows custom routes and redirects.
• Scaffolding can automatically create CRUD (create, read, update, delete) actions and templates for you and can be customized and augmeneted to fit your needs.
• Templates can be rendered by the views. Ferris uses the jinja2 template engine.
• Forms and Messages are ways of representing data submitted by a client that’s used to update a model. Forms are better suited for HTML pages, whereas messages are better suited for JSON consumers. These are exposed to the controller via request parsing.
• Components are a way of packaging common controller functionality into reusable classes.
• Behaviors are a way of packaging common model functionality into reusable classes.
• Plugins are a way of packaging entire parts of an application to be reused in another. If you’re coming from Django, plugins should seem very similar to the app concept in that framework.