Sidebar Menu

• Mission
• DRY
• IoC
• Light weight
• Testability

Mision

The design of SharpTiles and it's syntax if based on the following principles:

DRY

Don't Repeat Yourself
Microsoft did a great job with C# 3.5. The syntax was enriched with the var statement, property initializer, collection initializer, extension methods and Linq. All syntax enhancements for reducing the repetition and plumbing in your code. The .aspx syntax has fallen behind. As far as I'm concerned I'm just rendering HTML. This is especially the case when doing MVC, but I have to add information about base pages, code files, base classes, imported namespaces, my own assembly and a third party assemblies with a very specific PublicKeyToken.

1:<%@ Page Language="C#"
           MasterPageFile="~/the.master"
           AutoEventWireup="true"
           CodeFile="somepage.aspx.cs"
           CodeFileBaseClass="MyBase"
           Inherits="SomePage" %>
2:<%@ Import namespace="My.Business"%>
3:<%@ Register TagPrefix="3dtxt"
      Namespace="ThirdParty.WebUI.WebDataInput"
      Assembly="ThirdParty.WebUI.WebDataInput.v4.2, Version=4.2.20042.32,
      Culture=neutral, PublicKeyToken=324dfdsf234"%>
4:<%@ Register Assembly="My.Web.UI" Namespace="My.Web.UI" TagPrefix="myweb" %>


And for each new .aspx file I probably repeat 80% of this stuff. In SharpTiles taglibs are registered in code only once. After registering, the tags are available throughout all tiles and there is no need for registering assemblies in each file. Therefore lines 3 and 4 aren't required, furthermore a tile doesn't have a code behind. It's just a template without any knowledge of the business layer (loosely coupled). As a result there is no need for the import and description of the base class and code file and no need for line 1 and 2.

Inverse of Control

Reuse of components must be stimulated. How does Sharptile accomplishes this? Take another look at the previous code example and notice the MasterPageFile declaration. By declaring the master page file you prohibit yourself to use this page with a different master. What if I want to use my page on a participant portal and an administrator portal? Well you better do some nice stuff in your base page.

So why not use a UserControl? Well they aren't that bad but you will have a tight relation between parent and user control. For example you have one page which could show a bar graph or pie charts for some data depending on the picked menu item. So you basically want to slide in a different control for rendering the data. But what you end up doing is placing both controls in the page and disabling one or the other. Switching between the user controls is now page logic. Wouldn't it be nice to just configure this? It would definitely save you a couple lines of code. Dynamically loading UserControls is also an option but it has the same problem.

SharpTiles solves this by inversing and decoupling the encapsulation of controls. With the Tiles concept you have small building blocks (your tiles) and a definition file stating how your page is built up. See the following Java Tiles example

  <definition name="main" template="/layout/main.jsp">
    <put-attribute name="header" value="/jspf/header.jsp"/>
    <put-attribute name="menu" value="/jspf/menu.jsp"/>
  </definition>

  <definition name="participant.portal" extends="main">
    <put-attribute name="body" value="/jspf/participant/portal.jsp"/>
  </definition>


IoC containers solve the same kind of problem. The SharpTiles template engine supports tiles. The Tiles concept is adopted from the Java Tiles framework project.

Light weight

No heavy code base should be required. We want to be able to render html in a simple way. For rendering the SharpTagLib (based on JSTL) syntax is used. This provides a good balance between the amount of code and the available tags and their functionality.

Tiles don't require compilation. They are parsed and cached at first use. The SharpTiles framework will allow changing of definitions, tiles and resources while running the application as of Milestone 4. At this point only refreshing of tiles is implemented.

Testablility

This is a big thing. Aspx files and their code behind are not very willing to volunteer as test subjects. Mocking the HttpRequest, HttpResponse and or HttpContext isn't done easily and isn't pretty. Therefore you can run the SharpTiles template engine stand alone. Together with the Tiles concept this should allow you to narrow down your html render tests to small modular pieces. For integration test I refer to WatiN

As a matter of fact SharpTiles is developed with the TDD paradigm. With each binary download you get a test and a coverage report.