Web Application Famework Update

Project status: 80%

I have finished most of the actual Framework functionality. Now pages can be added to the Framework, provisioned and settings can be added.

I have built almost all of the management pages as an application using the Framework. Sort of "Eating My Own Dog Food". I have introduced a concept of "Super User" accessible pages. Since super user is an attribute of a user, not a role. Roles are based on the program (or application) that you are in the context of. So here's the list of managers:

Domain Manager
Program (or Application) Manager
User Manager
Role Manager
Menu Manager
Page Manager (not complete yet)
Data Connection Manager

Domain Manager - This page manages all domains for the Framework. A domain is a simple way to define and enforce password rules on a group of people. Rules include things like a password mask(regular expression validation), min password length, max password length, how many passwords to save in history (that can not be reused) and how often to ask for a new password.

Application Manager - Each "instance" of the Framework constitutes an application. Each application has it's own members, roles, menu and so on. This manager lets you create/modify applications as well as its defaults such as default database connection, default skin, default language and so on.

User Manager - uh, well, it lets you manage users in that given application. Now, keep in mind that a unique user is a combination of the username along with the domain they are in. I deviated greatly from DNN on this issue. This lets me have users with the same username in different domains. Each user can belong to only one domain, but they can exist in n number of applications. Also, strong security is used (thank you MS for the Enterprise Library and crypto! I am hashing passwords using SHA256!). You can also add a user to Roles from here. There is also a subset of this manager that allows a super user to define what users can manage what domains. This lets a domain user from domain X add users in domain Y. Needed for management purposes.

Role Manager - This is where roles are defined for the application you are in. This is pretty straight forward; it basically generates an id and a localized role name.

Menu Manager - This is where menu items for the application you are in are defined. I made this somewhat flexible, yet somewhat complex too. Currently the menu system is only 2 levels deep. It's a parent-child relationship mechanism. Each menu item can be defined as a link to a Framework based page, or to an external Url.

Data Connection Manager - This is where database connections are made, and to me makes the Framework worth all the effort. You see, with defining the connections at this level you can have pages that in their given instances can connect to external databases. This decentralizes the data structure and compartmentalizes all of the data access to the pages that the Framework hosts. It works this way: a super user defines a connection. Then the super user defines what applications can use that connection. In the page structure there is a Settings section. In that section there is a drop down list of all the available data connections, with the configured one for that page instance selected. When the manager clicks the save button, it's written to a table at the Framework level. This makes the entire system sooooo flexible. Now you can have a completely different database per customer, while still providing like functionality! For example, if we wanted a discussion page, the page would be built with the DAL expecting the connection string as one of its parameters. Since ASP.Net and ADO.Net are so driven towards the model of creation -> use -> destruction it makes perfect use in this case. Now, the only thing each client has to have in their database is the stored procedures the DAL expects and the data structure to support it.

Page Manager - I haven't built this one yet, but basically it will be a place where developers can upload new pages/language xml files/images/assemblies to the Framework.

I have also been working on two pages that will be used by the Framework for my company:

1. FileXplorer - since the page instance can also carry with it settings, it's a folder/file browser with download/upload capability that is configurable. The setting is where is the root folder. This allows us to give certain roles access to directories.
2. DataXplorer - This one is still being worked out, but basically there is a third database which contains report templates. The templates are XML documents that describe what the report filter needs to look like (i.e., Label, input type, data type of each element to expose as filters for the report) and what the output needs to do: such as the view/stored procedure to use, columns to use and display formats to use. This lets us create ad hoc reports that are super flexible and super easy. Now the results are pretty plain jane. Just a simple one dimensional table. The only real kicker here is that the template can also define a list of actions that are exposed on the row level as a menu, thus from the report you can send a user to some other page that has the context of what he clicked on (i.e., the userid of the row of the report).

I still have some work to do on the Framework, but it is coming along nicely. We are planning an extremely large Enterprise level application for the Framework. We have scoped the first release to consist of over 400 tasks and 4000 man hours. Wish me luck ;)