A quick update on MaVeriCk

I've been busy with some, paid (and therefore higher priority ;) ), work for the past week or so, which has meant I haven't had time to write up my Module Development in Maverick blog post.  I'll try to get that out next week.  In the mean time, you can pretty much just take the source (available here: http://github.com/anurse/Maverick) and start playing.  Creating a new module is as simple as copying one of the existing folders in the "Source/Web/Maverick.Web/Modules" folder, renaming it, and editing the "Module Application" class inside.  There's no registration necessary (thanks to MEF).

Have fun, feel free to post questions, and I'll talk to you next week!

MaVeriCk – An Open-Source CMS written in ASP.Net MVC

This is a big post, I know, but I think it’ll be worth it.  If you don’t have time to read it all, I organized it by importance, so the important stuff is at the top anyway :).

I’ve been hinting for a while that I’ve been working on a secret side project using ASP.Net MVC that was sort-of related to DotNetNuke.  Well, it’s finally time for me to put some code out there :).  Today, I published a source code package containing version 0.1 of MaVeriCk, a Content Management System written in ASP.Net MVC.  I’ll explain what it is and how to get started in this blog post.

Warning: MaVeriCk is nowhere near finished, and very much an alpha (maybe even a pre-alpha ;).  Major features are completely missing (such as user management, and any useful modules, see below for details)

Disclaimer: This project has NO RELATION to the DotNetNuke project.  While I am a DNN Core Team member, this is purely a personal side-project.  DotNetNuke has inspired some of the things I’ve done in MaVeriCk, but that’s the extent of the connection between the two.

What is MaVeriCk?

Maverick is an open-source Content Management System in the style of *Nuke applications such as DotNetNuke.  For the rest of this post, I’m going to assume you’re fairly familiar with that style of application.  Basically, users create pages and drop little widgets (or “Modules”) onto those pages to provide features like a Blog, Message Board, or even just a block of HTML.

Where (and how) do I get it?

The project is hosted on GitHub (http://github.com/anurse/MaVeriCk/) so you can feel free to clone the repository and hack away there.  Alternatively, if you either don’t have Git or don’t want to bother with getting the whole repository, you can download version 0.1.0, from the downloads section: http://github.com/anurse/MaVeriCk/downloads.  Also on the downloads page are the release notes for this version which include a full installation guide.  Unfortunately, there is no automated installation system, but the steps are quite straightforward if you’re familiar with ASP.Net.

Feel free to post comments on this blog, or send me email at: andrew AT andrewnurse DOT net

(After all, I’m just a junior programmer just out of college and don’t purport to be an expert in the various development patterns and architectures, so if you think something doesn’t look right, please let me know!)

How does it work?

The rest of this post will be a, very short, introduction to the Module Framework provided by Maverick.  I’ll be posting much more detailed information about the guts of Maverick later on, this is just a taste.  Feel free to send me email (see above) if you have questions about the rest of the architecture, and don’t be afraid to dive into the code!

Let’s start by taking a look at a MaVeriCk page:

image

Here, we see a page with two modules.  The first module is an instance of the “Current Time” Module Application, the second is an instance of the “Claim Dumper” Module Application.  A Module Application is an MVC Application, with its own Controllers and Views, which handles requests for a particular type of module.  If you’re familiar with DNN, the “Module Application” is analogous to the “Module Definition” concept in DNN.

Here’s a look at the code for the Current Time Module Application:

[Export(typeof(ModuleApplication))]
[ModuleApplication(ApplicationId, ApplicationName, "1.0.0.0", "Displays the Current Time", "Maverick", "~/Modules/CurrentTime/Content/Images/Icon.png")]
public class CurrentTimeModuleApplication : ModuleApplication {
    private const string ApplicationId = "A1FE2A31-0BC9-4B12-9B81-3B75C098EB33";
    private const string ApplicationName = "Current Time";

    protected override string FolderPath {
        get { return "CurrentTime"; }
    }

    protected internal override void Init(MaverickApplication application) {
        base.Init(application);
        RegisterRoutes(Routes);
    }

    private static void RegisterRoutes(RouteCollection routes) {
        routes.RegisterDefaultRoute("Maverick.Web.Modules.CurrentTime.Controllers");
    }
}

Compare this with the Global.asax file with an MVC app, and you’ll find it’s very similar.  The “Init” method is equivalent to “Application_Start” and is called the first time the Module Application is run during the current ASP.Net Application’s lifetime.  Just as you would in an MVC ‘Application_Start’ method, the Current Time Application registers routes into a route table for this module application.  In this case, the module is using a helper that Maverick provides to register the default route, but if we take a look at that helper, the only difference between the standard MVC route and this route is that we require that the namespace containing the Controllers is specified:

public static void RegisterDefaultRoute(this RouteCollection routes, string routeName, string defaultController, string defaultAction, string defaultId, string[] namespaces) {
    routes.MapRoute(
        routeName,
        "{controller}/{action}/{id}",
        new {controller = defaultController, action = defaultAction, id = defaultId},
        namespaces
        );
}

(Note: there are various overrides to this method, including the one you see used by the CurrentTimeModuleApplication class above)

Routing in Maverick is a little more complex than in standard MVC applications.  I’ll go into more details on it later, but the gist of it is that a portion of the URL for a request is handled by Maverick, and the rest (if any) goes to one of the modules on the page (called the “Active” or “Selected” module).  All the other modules (referred to as “Passive” modules) get an empty URL, and their default route is run.

From there on, a module is surprisingly similar to an MVC application.  It has Controllers and Views, just like an MVC app.  The big difference is that, in most cases, the ActionResult returned by a Controller does not represent the whole page, just a fragment of it.  Maverick collects all the ActionResults for a page and then renders them out one-by-one in the correct location.  Of course there are exceptions (for example, if a Module returns a FileResult or a RedirectResult), but that’s the core of it.

Missing Features

Maverick is in an early preview state at the moment.  There is a powerful authentication model available (or “Identity” model, as I call it), but at the moment, there’s only a very simple “Debug” implementation of it (which just automatically logs you in as an Administrator).  I have a prototype system which uses the Azure Access Control Service in the code, but it is not active by default (I’ll post more about that later).

Maverick does not really include any useful modules, so you’re on your own there.  Module development is relatively simple, and will be the focus of another blog post.  Feel free to check out the other modules for more info.  The only major component of Module Development not covered in the provided sample modules is data storage.  Maverick does have a system for modules to store data in the Maverick Database, but none of the built in modules do that.

There is a very rudimentary Theming system in place to allow you to create your own templates for the site (similar to DNN Skins).

Despite being touted as a Content Management System, Maverick doesn’t actually contain any Content Management features :), no Workflow, no Versioning, no Content Approval.  However, those features are planned for the future.

If you have any other suggestions, please let me know!

DotNetNuke Reports Module 5.1 enters the Release Tracker

It took almost a week longer than I said it would, but it’s finally done.  Version 5.1 of the DotNetNuke Reports Module is in the DotNetNuke Project Release Tracker.  I’ll post some more info over the next week, but for now, here are the release notes:

Reports Module 5.1 for DotNetNuke 5.0.1

Required DotNetNuke Version: 5.0.1 or above

The following issues have been resolved in this release of the Reports Module

  • RPT-9810: Simple URL Parameter system - A simple URL parameter system has been added which allows users to provide a list of QueryString parameters which will be added to the query. The parameter names are in the following format: @url_[QueryString Parameter Name]. Only the parameters specified in the "Allowed URL Parameters" section will be added.
  • RPT-5953: XSLT Extension Objects - CLR objects can now be provided to the XSLT Visualizer to use as XSLT Extension Objects. These objects must have a parameter-less constructor and MAY (but are not required to) implement the IXsltExtensionObject interface (found in DotNetNuke.Modules.Reports.dll) in order to receive additional context information.
  • RPT-7025: Search Indexing fails due to an exception - When there is an error in a Data Source, that exception is also thrown by the Search Indexer. Since Reports Module Exceptions were localized, through the Message property, when the Scheduler caught the exception thrown by the module, it would attempt to localize the text and fail (since there is no HttpContext). This has been corrected so that Data Source errors are no longer masked.
  • RPT-9543: Exception thrown when opening "Manage Add-Ins" page on DNN 5.0 - The DotNetNuke Extensions Installer API was moved to a different namespace in 5.0. The Reports module has been updated to reflect this change.
  • RPT-8145: Reports Module does not release file handle - The HTML Visualizer was opening a StreamReader and using ReadToEnd to load the contents, but not closing the StreamReader. It has been corrected to use System.IO.File.ReadAllText. A similar issue in the XSLT Visualizer was discovered and resolved the same way
  • RPT-7237: Show Info Pane working incorrectly - The "Show Info Pane", "Show Controls", and "Auto Run Report" settings were not being updated if the user is not a Super User, despite the fact that these settings are visible to non-Super Users. This has been corrected in the 5.1 release.
  • RPT-7236: Critical error when no file name entered for HTML Template Visualizer setting - The HTML Visualizer allowed users to leave the Template file field empty, causing a Critical Error on the view page. The view page has been corrected to avoid causing this error. A similar issue with the XSLT Visualizer has also been corrected
  • RPT-7238: Show Header field cannot be unchecked - A bug prevented the ShowHeader option from being deselected in the Grid Visualizer.

Also included is an update for the UDT Data Source for the Reports Module, here are the release notes:

Forms and Lists Data Source for DotNetNuke Reports 1.1.0 - Release Notes

This is a minor update to the User Defined Table Data Source for the DotNetNuke Reports Module. It has been renamed to the Forms and List Data Source, to match the new project name. Only one minor change is included: The stored procedure used to retrieve the list of Forms and List modules has been removed and replaced with (safe) dynamic SQL to reduce installation overhead. Requires DotNetNuke Reports 5.0 or above.

Track the progress of the module through the DotNetNuke Release process here: http://www.dotnetnuke.com/Development/ReleaseManagement/ProjectReleaseTracking/tabid/997/ctl/History/mid/3337/ItemID/394/Default.aspx