Nototriously Databased v0.23

With the Admin panel finished, it's time to start working the the player's UI. Ideally I'd like the user to log in and go directly to a list of all his characters in the various games. From there they should be able to:
 -  submit new turns
 - view the results of the previous turn
 - view their current dungeon state
 - view old turns
 - view public information for the whole game

PlayerController
Off to build a new controller. Most of the UI will be the same as the CharacterController for now, so it's a good one to pinch. Pretty easy < 2mins.

Limiting PlayerController
Looks pretty good, but is showing all characters, not the currently logged in user's characters. Since I haven't created the link between User and Account, I'll leave that for now and see if I can limit the list to a single ID.

After a number of false starts, it seems that grabbing everything from CharacterController wasn't as good as grabbing the extensions I did on UserController's edit action. Changed it over so that I could pass in a User model that is limited to the single ID and includes Characters.

User user = db.Users.Include("Characters").Single(u => u.UserID == 1);
return View(user);

Took a couple of hours of wrong turns and dead ends to get there, but at least it's working and looks pretty clean and simple. Now to change it to the logged in user...

Currently Logged In User
The intenetion of using the ASP.NET default account management was to make sure passwords etc were handled a little more securely than if I did it myself. The upshot of that choice meant that I'd make a User table that shadowed the account and use it to link all the game data to. Since I'd successfully added other tables when generating the creation of games, I set about modifying the AccountController to also give me a User record if they successfully registered.

Username and email were simple as they already existed in the Register action, but I'd also wanted to link the user table to the account using the guid. Try as I might, the standard code to return the logged in user's Id simply returns null:

Guid userGuid = (Guid)Membership.GetUser(User.Identity.Name).ProviderUserKey;

I'm assuming that the Register action has just created the account and they haven't actually logged in until exiting the action.

It would have been nice getting the account ID, but I'll have to suffice with the username. It'll be a little less secure, but fine for the scope of this little project. User record created and working!


Limiting to Logged In User
There should now be a User record for each account, and since the "User Info" page isn't visible until someone logs in, all I need to do now is find a way to get the current user. While searching for a way to get the account ID, there seemed to be a number of ways to get the current account name, so dropping back to username rather than ID has made this step rather easy:

User user = db.Users.Include("Characters").Single(u => u.Username == User.Identity.Name);  // assign currently logged in user
return View(user);

 Tidy up
Now that the page is working moderately well, I spent a little bit of time to rewrite the intro and remove / reword the character list fields to make it cleaner. All ready to make the submission...

Custom Data
For the next section I'll need to pass in some custom data to tell if the character is ready to submit a turn for their game. I might be able to do it in the view, but I confirmed through Andrew that it's definitely the controller's job to collect and prepare that sort of stuff. So how do I get it to the view when I am already passing in the User model along with associated Characters?

It seems that I need to create a separate model specifically for the view and pass in only the information that the view needs to display. I don't need all the Character fields, I do need some other fields from DungeonState and Game, and I also do need some custom variables to tell whether the turn needs to be submitted (or changed).

With Andrew's help, I made up a new ViewModel specifically for the Player controller with all the character information added as another class. In the end it felt more like creating a view in SQL from related data, but I could construct almost anything to put in there. A little bit of pre-work for a much more simple and clean implementation. I like it.

Now that the custom ViewModel is in place, I have to redo the way the Character table is laid out on the view. It needed a change anyway as I also took the opportunity to bring in all the data I'm expecting to show, as well as the IDs for all the relevant actions.  

Notoriously Databased v0.22

The next objective is to build an administration panel to link all the table controllers to. This will allow quick access to the game's internals in case the proper game fails.

•  Added an AdminController with a simple list of table links.
• Tested all links and found that CharacterSubmission controller failed due to pluralisation issues.
• Fixed CharacterSubmission to CharacterSubmissions in the db, and rebuilt the model and controller.

Now some initial prep work on the game. If a new game is created, it would be best to have defaults set up immediately for VillageState and Turns.

• Located the creation of game objects and added code for creating a new Turn object once successful
• Reviewed changing ID fields for the new record, but it looks like it does that automatically once saved. 
• Reviewed adding linked GameID fields from the original object. Does it pick up what the new ID field is once added? Yep, fantastic. Nice and easy.
• To check that all the IDs are working, I redid the display view for Turns. Entity Framework is a treat for getting related data out. 
• Formatted GameDate to Now() until I know when the game will be pitched at. 
• Added VillageState object, linked to the current turn, and saved.  

All in all a pretty good night's programming (plus F1). Slowly coming to grips with MVC / EF / C# and it now feels like I can put together data onto the page where I like. Will still have a little work to prep for user account interaction, but hopefully it's only a Google away from a standard solution.

Notoriously Databased v0.21

Now that the tables and relationships were mapped out on paper, I then put them into a fresh database. Pretty easy after finding out some autoincrement foibles in the previous testing. 8 tables in all:

Users will have Characters inside each Game. The Characters will have CharacterSubmissions for each turn in what to do with their dungeon, which, once processed, is stored as the DungeonState. The Game will also revolve around a single village, that has VillageStates stored for each Turn. 

(Almost elemental facts, but meh ...)

Generating the App
Next step was to create the new MVC3 C# app. There were a number of steps that I needed memory jogging on, but I finally got the app set up with the database brought in by adding an ADO.NET Entity Data Model class to the Models directory. 

Account Control
The standard template came with ASP users and login hooked into a separate db, and not having to recreate login scripts and password obsfucation seemed like a good thing so I set about attempting to integrate it. Since the final version will be hosted online in AppHarbor using only one database, it seemed logical to bring all the ASP database tables into my own db and possibly link into the User table.

After some research it turns out that placing relationships onto the aspnet_user table is a bad thing in the long run, so I left the original tables as they were and added another field to handle linking to the unique ID. Hopefully I'll be able to link them together using API calls once the whole thing gets going. Creating the aspnet_ tables was relatively easy with aspnet_regsql , and apparently there's a lot more stored procedures that I would have missed if I tried to bring it over from the generated db file.

Once the db's had been merged, the next thing was to get the models to be merged. After a little bit of frustration, it seemed that the AccountModels didn't like accessing the aspnet files under the entity data model, so it was easier in the end to leave the connection string as a separate connection adressing the db with a simple SqlClient. The future problem will be that once I move it all to AppHarbor, it will only migrate one of the connection strings internally, so I'll have to manually update the ConnectionString to permenently point to the online db. Shouldn't be too much of a drama as there's not going to be much separation between production and testing.

Adding Controllers
User accounts complete! Adding controllers for the new tables worked relatively well once I figured out that the Data context class it was after was the complete NotoriousEntities class. Since I had added and removed it a couple of times, I had to restart VS 2010 to get it to pick it up. I'd heard that I should be able to refresh the database if it changed (because dropping the entity model and recreating is a pain) and once you double-click on the edmx file you can 'Update Model from Database..' from the NotoriousModel. Tested and working MUCH better.

Moving to AppHarbor.
I followed the general instructions to set up the new application, but finding the git info still needed a visit to the knowledge base. After previous tests with local git, I'd settled on integrating it into VS 2010.  Right click on the entire project in the project tree enabled me to start up a local git instance, then update it either with the Git Pending Changes addon, or straight to Git Bash. The shell will eventually be more useful, as once the remote git is set up I'll be constantly running the update and push commands. Update is nicer in the addon, but I can't see a push.

AppHarbor with SQL.  
It was easy to pick the free SQL shared server, but finding the details of the server to manually connect once again seemed harder than I remembered. There some new configuation variables that indicated a different method for connecting, but I finally found the options I needed by going to the SQL server. The connection string is going to be the main one to the entity model, and because of that it also needed the resource metadata to complete the connection string rewrite. After looking at the output, I pinched the ConnectionString data for the server itself and placed it over the account model connection. Seems to be working, but getting errors. Doh! no tables!

Once connected using SQL Server Management studio, the next task was to get all of the tables across. From the local database I could run a 'Generate Scripts..' task and point to all the tables. Hopefully the aspnet tables will be fine coming across as I'm pretty sure I won't be able to run aspnet_regsql over on the server.

Databases look good, but running the app looks like there's still issues. No stored procedures. Looks like I can output generation instruction for all stored procedures as a script in itself, and with a bit of massaging I got it to work. Now I need a schema :/.

Looks like I can get all the elements from generating scripts, so back to square one. Generating the complete database brings in too much database specific changes, so I tried picking all the items instead. Some ALTER ROLE scripts were ging to fail, but the rest seemed Ok so I merged them and manually added the role members using the GUI.

Still having issues with the schema, stating that it's an older, incompatible version; a task for another day ...   

EDIT: After a bit of Googling, it seems that the schema was fine, just aspnet requires some data to validate against. A quick merge of aspnet data files and it's all working. Now to build an integrated admin panel for manipulating the game data directly...

Notoriously Databased v0.2

After discussing with Andrew the benifits of MVC3 and AppHarbor, I was finally convinced that it was the way to go for the next step of developing Notorious. Hopefully it will allow a little more freedom in testing as I'll be able to fully automate the process and serve it up as a web app rather than Google Doc forms. Been a pretty long journey to get all the setup in place:

 - Looks like I'll need MVC3, EntityFramework, and AppHarbor testing
 - MVC3 needed Visual Studio 2010 sp1.  (250Mb)
 - Downloaded Windows Platform Installer to speed up the process. It was able to get most, but not entity Framework.
 - Tested MVC3 apps locally.
 - Downloaded GIT and merged local app to cloud
 - Needed to move data over to SQL, so downloaded 2012 SQL Management studio (600Mb)
 - Needs Windows 7 sp1, so it and another ~100 windows updates later ..
 - Management studio didn't seem to work by itself, so decided to move to 2012 express as well (200Mb)
 - Installed and running, and apparently management studio 2012 now magically works.
 - Played around with developing tables, and then merging them into MVC using entity frameworks. Lots of guidance by tutorials as this was not obvious. Eventual model first approach seems pretty slick rather than building LINQ.
 - Merged to cloud and then needed to figure out cloud connection. I could see the db fine in Management studio using the given user / pass, but couldn't connect to it using the app. finally figured out that it's rewriting the connection string itself. All I needed to do was to provide an alias to the model's connection string and also the resource metadata. 5 hours :/.
 - Looked at merging the data in case I neded to to that later on, but couldn't get a nice, simple way to do it across servers (I'm pretty sure the apharbour user doesn't have the right privelages for most options)
 - Ready to go!

3 days to get into a position to develop, and possibly 20 hours. Most of that was waiting for downloads, so maybe 8 hours in watching tutorials and testing stuff.

With all the tucked away, I spent 1/2 hr designing the table layout for the new NotoriouslyDatabased app. After building the guts of it on Google Docs, it's going to be pretty easy to convert the logic, but the file layout changes might mean a different approach is possible.