When we design a web site, we absolutely must remember that the point of the web site has nothing to do with the web site itself or its the internal mechanics. Therefore, one of the core purposes of Themelia is to put the focus of web development on the perspective of the user. User's don't care about MyPage.aspx, Login.aspx, Home.aspx or other pieces of internal mechanics, they care about getting information (/information/, /report/, /contact/), making purchases (/products/hats/, /product/shirts/93873XL), and talking with friends (/chat/, /forum/). Because of this, Themelia allows developers to keep the end in mind when providing a web solution.
In traditional ASP.NET applications, focus is normally placed on the ASPX files first and then later some thought might be put into cleaning up the web site for easy access. That is, normally we think about default.aspx, login.aspx, and other files and later (if not temporally, then logically) ask the question "Can we alias or rewrite these to clean this up?" This type of design process is completely backwards. No one cares about your web site internals. They only care about the results. To the end of that result is the interface to the web site. Here we mean, not the user interface, but how the web site is accessed.
When designing a web application using Themelia, the thought process starts with thinking about path access, not file access. We also ask questions that developers rarely think about, but that are nonetheless critical: how do we want people to use this particular web site? How should it be accessed? What URL would a end user remember? What API path would help developers understand the point of a particular endpoint? Do we want to allow access to the entire application? How can we make it obvious that different parts of a web site truly are different? What happens when a person is not logged in? How do I want Google to see my web page? How attractive is my web site structure? Is the path to the corporate FAQ page easily readable on a business card?
These are questions of usability that, like questions of security, needs to be asked up front, not after the web site has already been designed, or, worst, built. Themelia helps you create successful web sites by helping you implement solutions based upon answers to these questions.
If you are creating an e-commerce web site, for example, perhaps the answers to the above questions brings you to the conclusion that you should have a logical structure as follows:
http://www.mydomain.com/
http://www.mydomain.com/login/
http://www.mydomain.com/logout/
http://www.mydomain.com/reset/
http://www.mydomain.com/checkout/
http://www.mydomain.com/faq/
http://www.mydomain.com/blog/ (patterned access)
http://www.mydomain.com/blog/2008/09
http://www.mydomain.com/blog/2008/09/September-Newsletter
http://www.mydomain.com/blog/label/hats
http://www.mydomain.com/product/
http://www.mydomain.com/product/shirt/ (patterned access)
http://www.mydomain.com/product/shirt/F1927349/
http://www.mydomain.com/product/shirt/M8172648/
This logical structure has no direct relation to the physical structure at all. In fact, the physical structure is absolutely irrelevant at this stage of site design and should be considered black boxed. Fundamentally, what we are looking at with this logical structure is every publicly accessible way of accessing the web site plus two patterned areas.
The first patterned area would be the /blog/ path, which could be Minima (a.k.a Themelia Blog Services). The second patterned area would be the /product/ path which allows public viewing of various products by product SKU and category type. In fact, the /shirt/ part of the URL may be completely optional as you obviously have no reason to require it as idea of "shirt" is redundant given the SKU; it would just be there for easy viewing. Both of these patterned areas as well as the other listed paths are easy to create using Themelia (more on this patterned access topic later on).
Themelia Web Site Structure
Of course, after (and only after) you have a logical structure approved for Internet (and real world) marketing, may create your physical structure. Though you could do anything you want, Themelia provides a standard convention to follow in order to optimize Themelia usability. Below is the basic structure of a Themelia web site:
Another major point of Themelia is that it provides unobtrusive ASP.NET development. There's been so much talk about unobtrusive JavaScript in the past few years, it seems that people forgot all about ASP.NET and have let it go to the waste land. In Themelia, you keep various entities together and keep as much stuff out of the root as possible. In fact, when using Themelia, you don't even use default.aspx.
The basic folders for Themelia are: Config_, Page_, Resource_, Sequence_, and Service_. In fact, Resource_ and Service_ are actually hard coded into Themelia to be special folders that may only be used for non-routing purposes (i.e. you can't alias /Resource_/ or /Service_/ or setup a handler in those paths). Here's the basic run down of the various Themelia folders:
Config_ holds the various configuration sections of the web.config. There's no reason to keep piling up the configuration in one monolithic file. It screws with versioning, it kills your ability find elements, and it destroys cohesion. By utilizing the extremely underused "configSource" attribute on configuration sections, you can greatly unobfuscate your ever growing web.config (or even app.config) files.
Page_ holds the various categories of web forms that your web site will be using. In Themelia, you don't use web forms in completely the same way you would in classical ASP.NET. Web forms are still web forms, but not all pages are web forms. By defaulting your thinking to a web form, you are short circuiting the design process. Web forms are for rich ASP.NET interaction. If you need some sexy form of some great grid of data, perhaps you need a web form. On the other hand, if you are handling a callback from PayPal, you need a handler. Similarly, if you are going to do a checkout process, you may not need a classical web form, you might actually need a Themelia sequence, a topic discussed in a moment.
Web forms in Page_ are also not accessed directly. Never will anyone ever access anything in /Page_. Access to a Themelia web site is only through its logical structure; it's physical structure is protected. To this end, use Themelia page aliasing for simple Page_ access. Remember, the point of the system is the logical structure, not the physical structure. You never want to think of the logical structure as being a byproduct of the physical. Instead, think of the physical structure being enslaved to the logical. Furthermore, remember we need to try to ignore the technology as much as possible. Yes... ignore the technology. We need to try to focus on what we want, not how to do it. For example, in the Page_ folder we may have a category of pages relating to security thus creating a /Page_/Security/ folder. Within the concept of Security, we have the idea of an authenticated home content, the idea of a login, and the idea of a logout. Translating this to the physical world means, in our /Page_/Security/ folder we may have Home.aspx, which is root page (note: the term "landing page" is meaningless in modern web applications as Google makes ALL pages landing pages) in addition to a page to Login.aspx. This second page would then handle both login and logout functionality (via page aliasing-- both logical paths map to the same physical path). It handles the entire idea of a login, which implies the idea of a logout. Within the page itself we would use Themelia mechanisms to detect which idea the user is accessing. Thus we may have something like this (note Http and HttpData are in the Themelia.Web namespace and Setting is part of the web application in the Sample.Web namespace):
//- #OnInit -//
protected override void OnInit(EventArgs e)
{
if (Http.UrlPartArray.Contains("logout"))
{
HttpData.SetScopedSessionItem<Boolean>("Auth", "IsAuthenticated", false);
}
//+ check security
if (HttpData.GetScopedSessionItem<Boolean>("Auth", "IsAuthenticated"))
{
Http.Redirect("/");
}
//+
base.OnInit(e);
}
In this example, we are using LINQ to detect what the user wants. Does this user and login or logout? Since only /login/ and /logout/ are aliased to this particular page, if its not /logout/, it must be /login/. Thus, if the user is accessing /logout/, we deauthenticate. We also check for authentication and redirect to the root if the user is authenticated necessary. Notice that even when working in the physical world, we are keeping to the ideas in the logical world as much as possible.
Resource_ holds all JavaScript, CSS, and Silverlight files plus any images and videos as well as any master pages for your application. Not only that, the concept of a master page is a classic ASP.NET idea. In Themelia, the concept of a "frame" is more appropriate. There may actually be various frames for a particular web site. That is, a general overarching look and feel into which content is placed. Even then, a frame may have its own set of resources. Perhaps you have a standard frame for most of the web site and an admin frame for the private administrative sections. The standard frame may have JavaScript and Silverlight files specific for its area and the admin frame may have nothing but a different style sheet. In any case, the idea of the Resource_ folder is to hold all support resources for your web site. However, it's not a "dump" zone for all kinds of nonsense. That place does not exist in any professional application and never actually has.
Sequence_ holds all Themelia sequences. A sequence is fundamentally a set of interactive ASP.NET files placed in a workflow. For example, whereas in classical ASP.NET, a contact page would be a web form, in Themelia it's a sequence with a view (a separate control) for input and a view (again, a separate control) for confirmation. A user comes to the first view of the contact sequence and enters the information. After the information has been submitted, validated (by classical mechanisms), and saved, the sequence then moves to the next view, which, in this case, may just be a thank you message. It's a simple concept, but it brings a feel of workflows to forms without needing to bring in a full workflow system to ASP.NET. Finally, as with items in the Page_ folder, nothing in the Sequence_ folder will ever be directly accessible by the outside world. Access is through the logical, not the physical structure. Access to Sequence_ is only through Themelia page aliasing.
Much of the same concepts explained with regard to the Page_ folder apply here as well. You want to make sure you are focusing on the logical structure, not the physical. You need to continually ask yourself the question "What is this?" Not "How should this work?" or "What should I use here?", but "What is this?" What something is is far more important than what something does. It's a bit easier to do this in the case of a sequence than it is with a normal page. The primary reason for this is that sequences enforce a logical internal structure. That is, all sequences are required to have a method called SelectInitView which always runs the first time the sequence is accessed. The SelectInitView which you will write will detect what the user wants and set the initial view based on that information. Here's a sample SelectInitView:
//- @SelectInitView-//
public override String SelectInitView()
{
String[] urlPartArray = Themelia.Web.Http.UrlPartArray;
if (urlPartArray.Contains("suggestion") || urlPartArray.Contains("contact"))
{
return "MessageInput";
}
else if (urlPartArray.Contains("problem"))
{
return "ProblemInput";
}
//+
return "MessageInput";
}
In this particular example we have the /suggestion/, /contact/, and /problem/ logical paths being mapped (via page aliasing) to the same physical /Sequence_/Contact.aspx file. When the sequence loads, it will then check to see what sequence view should load. In the case of "MessageInput", the MessageInputView will load and will then, in turn, do a check to see if the user requested "suggestion" or "contact". TO be clear, this isn't the time or the place for a full discussion of Themelia sequences, so simply understand how sequences like pages are to be thought of as supporting the logical structure of the web site.
Service_, as it's name suggests, holds all services. Since this is 2008, not 2005, your services will probably be WCF services, therefore, .svc files (Themelia requires .NET 3.5 SP1, so if you are using Themelia, you have WCF 3.5.) Furthermore, in just about every case, your Service_ folder will hold nothing more than .svc files each with only a single line of data. Below is an example of a WCF service host file. This is all that's required to get the job done, therefore, that's all that should be there; it's an entire WCF service host.
<%@ ServiceHost Service="Sample.Web.Service.PersonService" Factory="Sample.Web.Service.Activation.PersonServiceHostFactory" %>
In addition to the folders, notice also that the root contains just about nothing. In fact, one thing that's conspicuously absent is the default.aspx file. That's not to say that there isn't a default, but the default is a page and is, therefore, placed in its proper home in Page_. If you have a nicely organized structure for all your web forms and forget to move your default.aspx from the root, then you don't actually have a nicely organized structure for all your web forms. In Themelia, the simple default.htm file signals to the developer as well as to Themelia, that the default.aspx file has been moved. The Themelia configuration file handles the rest from there (see Default Index Redirect for more information).
Themelia Web Site Structure Example
Now that you have an overview of the various folders in a conventional Themelia web site, let's see a full example of this. Keep in mind that all of the paths in our previously mentioned logical structure requirements may be handled with the following structure.
Notice that this physical structure looks nothing like the logical structure. It shouldn't. If it does, you're seriously doing something wrong because the logical structure of a web site is for the common person, for their memory, for business cards, and for commercials whereas the physical structure is for the developer to allow him or her to locate and understand physical documents. For example, whereas the common user will probably be able to remember domain.com/blog/ and domain.com/product/, there's no reason a developer has to put up with /Blog.aspx, /Item.aspx, and myriad other files just haphazardly thrown into the same folder. What in the world does blog.aspx have to do with product.aspx? Just about nothing.
The point isn't the technology, the point is the concept each entity represents. One represents a blog, the other a product. Therefore, the developer needs to keep them separate so that others may quickly track down the exact type of page. In the above structure, we see that Blog.aspx (which, by the way, is all Minima requires) and Faq.aspx are declared to be "Information" and Item.aspx is declared to be "Product". Would you throw all your files into the root of your hard drive? Of course not. The physical and logical organization structures of a web site have different purposes, different concepts, different audiences, and often times different types (i.e. Checkout.aspx, mapped from /checkout/ is a sequence and Blog.aspx (mapped from Minima) is a page.) Clean physical organizational structure, while not nearly as important as logical organizational structure, allows for efficient use.
A Deeper Look
There are a few things I would like to point out regarding the above structure. Let me go through them point by point:
First, notice that the standard frame has special resources that the admin frame wouldn't access. Since only the standard frame will access it, it makes no sense to have an organization structure that implies that both will. Therefore, by way of example, the logo is declared to be associated with the standard frame only.
Second, notice that Communication.xap is in the /Resource_/Silverlight folder, not in the /ClientBin folder. An ASP.NET web site uses the CLR and places special significance on the Bin folder for assembly binding. Silverlight (we're talking 2.0 here) on the other hand uses the DLR and places no significance on any folder. A Silverlight application compiles into a xap file, is self contained, and has no requirements on where it should be. It's a resource, not a special piece of ASP.NET (in fact, it's a client side technology that our PHP friends can use as well.) Therefore, it's very misleading to have it in the /ClientBin folder as the default suggests some relation to idea behind the /Bin folder (it's my bet that the mere existence of the /ClientBin folder will bring no end to confusion to people.)
Third, notice that the Page_ folder is organized into the various concepts of pages. Instead of just throwing them into one folder, they are
