Maverick.NET Framework

Maverick.NET is a .NET port of Maverick, a Model-View-Controller framework for web publishing. It is a minimalist framework which focuses solely on MVC logic, allowing you to generate presentation using a variety of templating and transformation technologies

Features :
• Pluggable view templating technologies.
• Pluggable transformation technologies.
• Support for iterative transformations.
• Configuration using an XML sitemap.
• Framework support for internationalization, customization of content based on browser, and WML.
• The ability to use standard ASPX pages as Maverick controllers. There is full support for Server Controls, Postback forms, and View State.
• A fairly exhaustive set of sample applications using a variety of templating languages and controller types.

Depending on what templating technology you choose, you may be interested in one or more of the following features:

• Automatic XML serialization of arbitrary objects so that XSLT transformations can be used without the effort and processing overhead of generating and parsing text XML.
• The ability to halt iterative transformations at any step and obtain the intermediate result. In the case of XSLT and DVSL, this would produce static XML. This allows designers to build template files offline with simple tools.
• "Wrapping" transformations using basic templating languages like ASPX. This allows varying content to be easily encapsualted within a common layout, look-and-feel, etc.
• NFop transformations which can produce PDF documents on-the-fly.
• NVelocity and DVSL (an XSLT-like language based on Velocity) templates are now supported through the Opt-NVelocity package.

Working :
There are two basic phases in the life of an executing Maverick application. The first is the "load" phase which (usually) occurs once and uses the config file to construct a tree of workflow objects. The second is the "execution" phase in which http requests are serviced. Maverick is designed to perform as much work as possible during the load phase so that the execution phase can be as fast as possible.

The workflow tree constructed during the load phase represents all of the possible execution paths for servicing an http request. It consists of objects which implement various interfaces, and many of the objects are created by pluggable factories. After the workflow tree is built, the overhead Maverick itself adds to a running web application should be little more than a couple IDictionary lookups and a handful of virtual method calls.

The top level object is an ICommand object, which corresponds to a single defined command in the config file. Other than special implementations like the reload command, there are two basic implementations of the ICommand interface: CommandSingleView and CommandMultipleViews. The CommandFactory will automatically build the correct instance depending on how many views are available; the only difference is that CommandSingleView can eschew the IDictionary lookup to deterimine which view to render.

There is always one IController associated with every command; a simple null controller is generated by the ControllerFactory when no controller is specified by the user. In addition, it should be noted that from the perspective of the command objects, controllers always look like singleton controllers; a special ThrowawayAdapter is used for "normal" controllers.

The command object chooses an IView to render. IViews are built by the flexible IViewFactory system. At runtime, execution passes from the ICommand to the IView identified by the IController.Go() return value; the IView is responsible for "dealing with" the request from here out. There are many types of views.
If an IShuntFactory was defined in the modules part of the config file, the IView instances held by a ICommand will actually be instances of the decorator ViewShunted, which holds an IDictionary of real views and adds the mode switching behavior.

Actual IView implementations are responsible for tasks like sending HTTP redirects, or rendering the model using an ASPX page. Output is rendered through an ITransformStep object obtained from the IViewContext passed into Go(). Depending on the configuration in maverick.config, the ITransformStep may be the entry point for a sequence of transformations or it may actually dump the results directly to the response output stream.

Thus, at execution time, an HTTP request is serviced like this:
• The Dispatcher receives the request and looks in an IDictionary for the ICommand associated with the particular URL. ICommand.go() is called.
• The ICommand calls Controller.Go(). The controller optionally sets the model object (using a method on IControllerContext) and returns a string indicating the name of the view to render.
• The ICommand looks in an IDictionary for the IView to render. IView.go() is called and passed a IViewContxt object.
• If shunting was enabled, the IView will actually be an instance of ViewShunted. This object uses the IShunt to find the actual view to render; the actual mechanism for this is specific to the shunt.
• The IView generates some content and sends it to the ITransformStep obtained from IViewContext.NextStep. If there were no transforms defined, this step will actually be a special implementation that sends output directly to the real response.
• ITransformStep objects are chained together such that one passes information to the next. Eventually the data gets passed to the special implementation which sends output to the real response.