Web Framework Getting Closer

Its the end of the week now and I am getting closer to having the core runtime of the framework functional. Yesterday I worked on exposing a submenu and context menu system to the developer via the Framework API.

I use the ComponentArt Menu control (highly recommend it). I made the sub menu by adding an actual menu control to the page navigation control that everyone will be using. Since it is visible on each and every page no matter what the state of that page is, it made sense to place it there. Plus by using a usercontrol instead of dynamically adding it at run-time I don't have to worry about viewstate. But the nice thing about doing it this way is I give each developer a way to do in page menuing, but they don't have to know anything about how to use the component. Plus I get to regulate the look of the menu itself.

I also bubbled the ItemSelected event back to the framework superclass and down to the page itself. Now a developer can trap a server side event on a menu click.

I also added a context menu, except with this one there is no pre built menu control. This one is added dynamically at runtime. The reason I did this one this way is because with context menus you usually don't care to persist it. It will almost always change when the data on the page changes. A developer can persist it by placing its constructor within certain events on the page with in that pane.

I also have finally gotten my VS.Net custom project and custom web page items working. I plan to deploy to other developers an installer that has those items as well as all the dll's associated with the project. Since I am requiring that a page be constructed a certain way (each page must have the 4 panes of context and references to the Page Navigation user control as well as the Wizard User Control and the Form Submit user control) it is almost a must have.

I also finalized my user control designs and have implemented them(the ones I just mentioned). I was at first attempted to do them 100% dynamically, but I found it was just to darn difficult to manage the state of each control when other controls are throwing events left and right and all the time the framework was trying to keep them straight. So, they are now statically built controls with rich eventing and business logic in their own code base (which makes sense from a code management stand point. I mean, these are probably never going to change once we launch anyway).

So that's it. It's been a good week. I will spend the rest of the day working on exposing a translator function in the framework. This will work by giving a developer a single method to get a string: Translate.GetString(mylanguagefile, mykey, currentlanguage). Each developer will need to provide a language file with his/her code. It will be a predetermined XML formatted text file that will go with each page. I am explicitly not going with the resource file concept that MS is pushing because this is a much more elegant solution. The file will be simplistic and only hold strings (I can't find a good reason to keep any other type of data). And keeping it this way will make it easier for us to just send the xml files to a translation company and have them fill in the blanks. The Translator will also take care of caching the data from the xml file with a dependency on the file itself. That makes it a performance rich method since the files will almost always stay in memory(and relatively small amount too). It also allows a developer to have more than one language file. But it is easier to translate because we have one key with all the language translations in the same place instead of being spread out across multiple files.

Custom Eventing Finally Used!

One issue that I ran across today was how to control from the super class level what content area to display at the page level. Custom events was the perfect scenario.

Anyone who has worked with asp.net has worked with Events. Its a way to notify an object of a change in another object. For asper's it is a new frame of mind.

So I have a super class that all of the pages in the portal will inherit from. Part of that super classes job is to add a navigation control to allow the user to switch between the different security context in the page. My current security objects are:

View
Edit
Settings
Personalization

Each one of these rolls down to a panel. The panel must be defined on the page. The super class compares the rights a user has to determine if he can see that panel. Only one panel at a time can be visible. So the navigation control has 4 buttons(image buttons) that show as active only if the super class has determined that the user has the correct policy at run time.

The interesting issue this brings up is the fact that the navigation may know what to show, but how does the programmer know when to do stuff to his objects contained in his page within those given security context.

What I ended up with is a set of custom events at the super class level. Part of the security logic decides which event to fire, and the developer can override those events at the page level to add binding of data to his controls at run time.

Works perfectly!

Ahhh. Enterprise Library...

I have been using the Application Blocks that MS published for a few years now. I have used the Data Access Block exclusively for the base of my Data Access Layer for at least two years now.

I had heard about the Enterprise Library release in January. I read some of what it offered. It seemed to be more of a wrapper of several application blocks at the time. Boy was I right.

MS has done a nice job of placing such a great wrapper around stuff that I would have to normally manually do. For example, I needed to develop a login procedure that used hashed passwords. I know its been done for some time now, but it's always been a very manual process. The EL has a cryptography class that is very well executed. In about 3 lines of code I had something that would retrieve my password from the db (hashed value) accept my password from the user (clear text) and one method returns a bool letting me know that the password given would in act match the hash in the db. Nice.

The best part about the EL is the Configuration Console. It's a simple little configurator that comes with the package. It simply opens up your .config file you point it to and lets you add blocks and configure them properly. That was always my biggest peeve with the blocks as they were, because some blocks required other blocks to work, and they had to be configured just so. Now MS has taken that load off the developer and given us a way to deliver Enterprise level software easily.

Thanks MS :)

Security Scenario

One of the first issues that I had to provide a solution for was security in a multi-tenant hosted environment. I knew that I wanted it to be roles based. I also knew that I wanted objects that are generic enough that they can be configured at the UI level to interact with a new clients data store. However, my boss threw a third curve at me earlier this week: Each page, or function, had to not only be reusable client to client, but it also had to be reusable within the same client. Yikes!

So with that added dimension I set out this week to develop the security model. Here's how it works:

A Page with functionality is developed using the four main category pillars: View, Edit, Settings, Personalization. Each one of those can be configured with roles to gain access. So, if you want users to be able to view the object, then you would assign those roles to that security pillar.

Next, I created a scenario where the page is assigned to a portal. But not just the page, but an instance of the page. That way you could have the same page appear n times in the same portal, but with different configuration and security settings.

So this created a four dimensional security model:

Portal, Page, Page Instance, Role

Each user must satisfy all of these parameters before the Framework grants them access to the resource. It also gives each developer the rare chance to make a page Über-configurable. Now you not only have to construct the page to have a single configuration, and not only configurable at the portal level, but now must support multiple configurations in the same portal.

Since the Framework is what takes care of the authorization to the resource the developer can use those same credentials to manage the configuration settings for that given instance. This model leads to an unforgiving demand for flexibility.

Design Decision Made

We have made a decision on how to structure the framework. That's what we're calling it now, a web application framework.

There will be a central framework that all pages will derive from. The framework will provide the lower end functionality; Security, Themes, Menus and Exception Handling. The framework doesn't really care much about the pages it is encapsulating, except that they impliment certain Interfaces and that they have a certain structure. As far as the functionality goes, the framework doesn't care what the page does.

Each page will contain 4 objects. The objects are simply aspx panels, but there will be either a custom control that provides that or a project template that will drive it. Pages are going to be uploaded to the server through a web interface and the framework will validate the page structure. I'll talk more on that at another time.

On the data side we have decided to go with a distributed model. One of the functions of the framework is to determine what data connection to use at a given instance. So, for example, let's say a page provides a discussion group. When the discussion group page loads it asks the framework what data connection do I use at this particular instance? The framework responds based on the page and the context of the user. Since this is multi-tenant a page is supposed to provide functionality to multiple users without collision.

So, we will have a central framework database. This database will only keep information that is relivant to itself. The only thing it knows about the other pages is what their URL is, what roles to grant access to what modules, and what dataconnection to use. All the rest of the functionality of a page points to child databases. This will give us maximum scalability (data wise), allows us to determine by client where the database resides, and provides us a security mechanism that completely seperates clients data from other clients.