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.