The Waffleshop

One of the new features in ASP.NET MVC2 is support for areas – a way to organize large projects and group code for specific sections together. For example, instead of having ~/Controllers/HomeController.cs and all the related views in ~/Views/Home/, you have ~/Areas/Home/Controllers/HomeController.cs and the related views in ~/Areas/Home/Views. This might not seem like a big deal, but the larger your project gets the more you come to appreciate the little things like this.

While this new feature is part of ASP.NET MVC2, developers using MVC1 are not out of luck; with a little bit of code (most of which has already been written for you) you can achieve the same effect. The first thing you need to do is create the folder structure. Since MVC2 uses the root folder ‘Areas’, I will too. Inside this folder, create a sub-folder for each of your areas; for this example I chose to create a folder for ‘User’ and ‘Admin’. Inside each of your area folders, you will need to create folders for ‘Views’ and ‘Controllers’. Note that you can create a models directory if you want, but you should consider putting your models in a separate solution.

Lets start with the controllers. MVC doesn’t care where you place controllers – they don’t even have to be part of the project (the can be part of a referenced assembly)! One problem you might run into, however, is creating multiple controllers with the same name. For example, both our User and Admin areas will have a HomeController. You should put the controllers in different namespaces, like so:

Mvc1Areas is the base namespace used in my example solution, Mvc1Areas. All controllers go in Mvc1Areas.Controllers.{AreaName}. Following this pattern, the controller for the User area is in the namespace Mvc1Areas.Controllers.User. When you create your routes, you can tell the MVC framework what namespace to look in; we will take a look at the routing configuration after views.

Now create a new MVC View Page in Areas/User/Views/Home named Index.aspx. Unfortunately, the MVC framework will not find it yet. View files are found by the View Engine, which has a list of search paths it will look in to try and find the requested view. If you use the .NET Reflector to inspect System.Web.Mvc.dll, check out WebFormViewEngine:

. This is the default list of locations searched. {1} will be replaced by the controller name, and {2} by the action. We need to edit this list to support another parameter {2} which can be filled in with the area. Unfortunately, this turns out to be a bit of work. Fortunately for you, all that work is already done:

Notice that we added search locations with a ‘{2}’ placeholder, which is filled in with the area name. Add this file anywhere in the project; I put it in the root Views directory. Note that this is not a stand-alone view engine; it is a wrapper around the default WebForms view engine. Now you need to tell the framework to use this view engine instead of the default one; add the following to the end of your RegisterRoutes function:

This removes the default view engine and adds ours.

So we have our view engine that is aware of our views, but how do we tell it what area to look in? And where do the namespaces for our controllers come into play? Take a look at the following code used to register our routes:

You will notice that we are adding an area property in the third parameter. This property is read by our modified view engine and used to determine where to look. Also notice the fourth parameter, which you might not have had need to use before. This parameter lets you specify a list of namespaces to give higher precedence to when choosing the right controller.

And there you have it! The AreaAwareViewEngine is based on code found on a relevant StackOverflow question, so kudos to Aaronaught for laying the foundation for this. You can download an example project. Please leave a comment with any suggestions, feedback, etc etc. I would love to hear from anyone who finds this useful!

This is a follow-up to my previous posting about using Flex and Bison together in C++ mode. This new example actually does something useful: parses an INI file and gives easy access to the values. Just like the last example, this is not a tutorial. Download the source code and give it a read – I tried to make it as straightforward as possible.

Download the source code.

This example uses the parser and the scanner to extract data from a stream into data structures. Once the stream has been parsed, there is no more need for the parser / scanner. Instead of having them as member variables of the class, they have been moved to local variables in the function that parses the stream so that we aren’t wasting memory keeping those class instances in memory when they no longer serve a purpose.

This example also keeps track of locations using the yylloc variable so we can tell where an error occurs. If an error occurs, an exception (of type std::string) is thrown that says what the error is and where it occured (line number, character number).

The Makefile for this example is greatly improved; builds are now incremental (files that have not changed are not recompiled).

I am NOT an expert on Bison, Flex, C++, Makefiles, etc. and have coded this as a learning experience. It is provided in the hopes that others will be able to learn from it. If you notice anything that can be improved on, please leave a comment so that other visitors as well as myself can benefit. This code is provided under the WTFPL license with no warranty.

Flex and Bison are used together to create parsers, usually for programming-related tasks like parsing source files or SQL statements. While not as easy on the programmer as newer libraries like Spirit OR ANTLR, they are more efficient since they generate raw C code that can be compiled into your application. They are also capable of outputting C++ code, but there is a lack of clear documentation / examples available demonstrating this.

What I present here are my efforts over the last couple of days towards creating a program that uses the two together in C++ mode. The result is trivial – numbers are recognized and divided by five – since the focus of this program is to demonstrate using Flex and Bison. If you do not know Flex and Bison, I recommend Lex & Yacc by Tom Niemann (Flex is a clone of Lex, Bison is a clone of Yacc).

Download the example source code here.

This is an example, not a tutorial – I’m not going to take you through the code line by line. I do have some notes for you, though:

• waffleshop.y
  • The require line tells Bison that this is meant for Bison 2.4.1. While it might work on other versions of Bison, the C++ code generated is ‘experimental’ and subject to change between versions.
  • The skeleton line specifies an alternate template to use – lalr1.cc is the C++ version.
  • The parse-param options tell Bison that we want the class to have an additional member variable – the scanner. Since Bison calls the scanner to get a token, the Bison class needs to have a reference to the scanner. The lex-param option tells Bison that when it calls yylex, it should pass the scanner as an additional argument. Our implementation of yylex invokes the passed scanner and returns the result.
  • There are two sections of code: the first is ‘%code requires’. The code inside of this block is put in the generated header file as well as the c file. The other %code block contains code that only goes in the c file, and since we don’t want anything else calling the yylex global function we make it static to the file.
• WaffleshopParser.h
  • This is a convenience class that bundles the parser and the scanner together; it is good Object-Oriented design to do this, and is recommended in the Bison documentation.
• WaffleshopScanner.h
  • FlexLexer.h is provided by Flex, and defines the base class that generated Flex scanner classes inherit from. The preprocessor directive surrounding it is necessary because FlexLexer.h is a mess (it says so right in the Flex generated code on line 16).
  • The yylex function has to be overloaded because Bison passes a pointer to the yylval variable. It would be nice if we could just specify this in YY_DECL, but the base Flex class has yylval with no arguments defined as pure virtual, forcing us to implement it anyway; I just went ahead and used it.

I used the following resources to construct this example:

• Flex Documentation
• Bison Documentation
• Timo Bingmann’s example

Please post any suggestions or questions – I am no expert on either Flex or Bison and am always interested in improving my code!

Update: After you have gleaned all you can from this example, check out this followup about creating an INI file parser using Flex and Bison in C++.