Dashboard > Bistro > 0 to hello world in 30 seconds flat
0 to hello world in 30 seconds flat Log In   View a printable version of the current page.

Added by Admin , last edited by Admin on Mar 15, 2013  (view change)
Labels: 
(None)

Getting started

bistro is an alternative implementation of the classic Model-View-Controller design pattern, using the Velocity templating language as the main rendering engine. Bistro combines concepts from REST and AOP to build a highly scalable application development framework. This document is intended to give you an overview of the bistro framework, and direction on where to get more information.

The bistro stack

bistro is the controller layer in a standard MVC implementation. The whole stack consists of an extended Velocity templating engine, the bistro controller framework and the wfs orm model layer and assorted goodies.

The almost-0-configuration "hello world"

Aiming to get application development going, all configuration options in bistro have defaults, and can be omitted. Want to get started? Keep readin'. Want to tweak? Read the Reference Guide

To get going, all you have to do is plug in the bistro module (sorry, folks, to get extension-less URLs working with ASP.NET, you gotta play nice with .net 3.5, so have either mono 2.4, IIS7, or the Visual Studio 2008 Development Server).  For running Bistro applications on IIS 5.1/6.0 see Running Bistro Applications on IIS 5.1 or IIS 6.0.

web.config
<modules runAllManagedModulesForAllRequests="true">
	<add name="BistroModule" preCondition="" type="Bistro.NVelocityIntegration.Http.NVelocityModule, Bistro.NVelocityIntegration" />
	...
</modules>
<handlers>
    <add name="BistroHandler" path="*.bistro" verb="*" type="Bistro.NVelocityIntegration.Http.NVelocityHandlerFactory" resourceType="Unspecified" />
	...
</handlers>

and start writing code!

using System;
using Bistro.Controller;
using Bistro.Controller.Descriptor.Data;

namespace Test
{
    public class Default : AbstractController
    {
        [Request]
        protected string message;

        public override void DoProcessRequest(IExecutionContext context)
        {
            message = "hello world!";
            context.RenderWith("default.bistro");
        }
    }
}

Following the defaults concept, this controller will respond to a request /Test/Default. Now, there's just one thing missing - a template, but that's easy enough:

default.bistro
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>my first bistro app!!!!!1!!ONE!</title>
</head>
<body>
$message
</body>

Done!

But we're just scratching the surface. Here are some of the other things you can do

Think resources and actions, not URLs and controllers

We like REST, and we don't care who knows it. We like it so much, that we think that when you build an application, you should think of it as a collection of resources that are consumed by the browser. The application exposes an interface that can be invoked through GET or POST HTTP methods, each URL it understands being a distinct resource. That puts more control in the browser, and less navigational complexity and interdependence in the server.

Define smart URLs and small controllers

Use Bind attributes to specify what incoming requests should trigger what controllers. We don't map different actions to different methods of a single class because we think that each action shouldn't be tightly coupled with another. That way, if you want to do a /search and also want to /search/bytag/stuff, your bytag controller does need to know how to perform a search, and your search controller does need to know how to figure out what tags you want to search by.

Build your security policy where you use it

Using a deny-first security policy and security controllers, you can specify security policy alongside the code that will need protecting, not in an external config file.

Build loosely coupled chains of controllers

Since a single request can be processed by multiple controllers, we have a sophisticated, but easy to use system of specifying the order things run in. Session and request scoping attributes along with dependency definitions on fields tell the system what the implicit interdependencies are, without tightly coupling controllers. This way, the runtime knows what things need to happen in order, and wings it on the rest.

As a result, the system can dynamically parallelize request execution, and even split request execution among multiple physical hosts.

Powered by a free Atlassian Confluence Open Source Project / Non-profit License granted to Workflow Server. Evaluate Confluence today.
Powered by Atlassian Confluence 2.7, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators