This project is read-only.

Interesting Armory Behavior

Jan 14, 2008 at 5:01 AM
I'm looking at adding a feature that allows a list to be created for each roster that lists people from the armory dump that should not be displayed.

I've noticed that when I person is removed from a guild by a guild leader, the Armory website doesn't remove that person from the guild until that person logs in again. If that person doesn't log in for quite a long time, that can result in "ghosts" from the Armory dump that aren't really in the guild anymore.

Ideally, the list would be setup in such a way that when the dump no longer sees that name, the name would automatically be removed from the list.
Jan 14, 2008 at 4:22 PM
This could work.

I used to (before this was a CodePlex project and before hooking it up to the Armor) have a 'delete' button on the character entry screen. What currently happens with the code is that when a char is no longer in the guild, it marks them as 'no longer current', which means the system still stores them, but the web doesn't display them. This allows you to potentially look at when people 'left'.

I could add in a flag in the database that says 'user override - hide this char', which would remove them from the roster for all intents and purposes. The downside to this is that if they join the guild again, they won't automagically show back up - it will require some manual 'okay - show this person again' interaction. The only other way to do this is when they fall off the guild (the 'no longer current' flag pops up), it auto-clears the user override flag.

Thoughts? Or did I geek out too much on you with my response?
Jan 15, 2008 at 4:11 PM
I think you're on the right track. Hiding/perserving "deleted" data is always the better way to go imo.

I would like you to entertain this thought. Would you be interested in developing your model in such a way that other models could use your data structures in the database for other means?

For example, if I'm a DNN admin looking to add 5 or 6 different WoW modules to my site, I can either use a suite of modules that work with eachother, or I can have each module standing entirely on its own. The work in setting up several modules related to players would then be considerably more.

It would certinaly be easier for me in developing a dkp system. If I knew that I could rely on this roster table behaving a certain way, I'd immediately use it as my player list for the dkp as well.

I'm thinking along the lines of a module scheme similar to the DNN Blog module package. 5 or 6 different module interfaces, but each connected to the same data structures.
Jan 15, 2008 at 7:11 PM
Edited Jan 15, 2008 at 7:12 PM
That's completely possible.

I checked in my v1.1.1 code last night - the only outstanding changes checked out is surrounding using 10 guild ranks rather than 6 - and that is ALMOST done (I have a bug somewhere in my display logic for guild ranks 7-10 right now)...but I digress...

If you look at the way I designed the code, it's set up as a series of assemblies - and each assembly has it's own data and business logic. I did this on purpose to allow multiple presentation layers without the need for recode.
  • Common Assembly - this has most of my functions for UTC conversion and dealing with DB Null values in a consistent way
  • GuildRoster Assembly - this has all the business logic around rosters, char entries, and stats, data loads, and errors - and has the data provider code. In my code I use this roster assembly for both DNN and a Windows rich client using different .config files (for Win client, using the app.config, and for DNN using the standard .config without modification). This assembly has all that you would need for calling into my WGR data tables (which are completely independent of the presentation layer logic); all you would need to do for a DNN DKP system would list this assembly as a pre-requisite for your module. And, if you want, I would be willing to separate this DLL out to another code plex project to separate that effort from the presentation layer, or simply add you to this project. :) This was also done to prevent the need for any System.Web assemblies in the core business logic.
  • LoadLogic Assembly - this has the Armory load code. I would ideally like to make this a generic abstract assembly and create a LoadLogic.Armory assembly that is loaded using reflection to allow a plug-in model for the WGR code. This also means that only this assembly has a dependency on the Kralizek.WoWArmoryParser assembly.
  • UI Assembly - does nothing currently, but I would like to create server controls here that can be called in either ASP.NET straight or DNN modules, which would allow much easier generalization. I spent a week or two trying to do this up front, but my kung-fu is weak in this territory and I gave up. :)
  • UI.DNN Assembly - Contains the presentation layer logic for DNN and also data layer overrides for the GuildRoster assembly, which allows the roster to account for module visibility. Also, my data layer code has separate WGRDNN tables which tie the generic implementation to DNN specifics - modules for visibility security enforcement as well as linking characters to DNN user accounts. This is all genericized to allow for exactly what you're asking for (I think).
  • UI.Windows Assembly - An implementation of the code using a Windows UI. I was using this for testing the business logic of the assembly before I coded up the DNN interface...and also helped me identify bugs in business logic before growing it into a presentation layer.

I don't know if you find the design convoluted or helpful, but I tried creating it with modularity in mind. My hope was to use this as a launching pad for having plug-ins that could be done for events, GEM integration, as well as DKP/Suicide Kings type of modules. What do you think?
Jan 15, 2008 at 8:12 PM
I think the layered approach here would work well. The language you're using isn't one I write in a lot. I tend to stick to VB since that's the portal's language, but here appears to be a good reason to become more proficient in C#. I'll start looking at code tonight, just the code specific to the data layer. I'm glad my MSDN subscription was still active. VS 2008 looks nice. :)
Jan 15, 2008 at 8:33 PM
One of the nice things about .NET is the ability to have different assemblies have different languages - so you could always progress with the DKP stuff in VB.

I prefer C# because I started off coding in C forever ago (well, started out in LISP, but that's a story for another discussion thread) and just prefer the brackets for aesthetics - although I really like VB for not having to type-cast everything.

<Geek On>
As for VS2008 - I really like it - many improvements on the ASCX designers and improved debug experience (plus I'm running Vista, which means less issues with VS2005 SP1), and the Javascript debugging will come in very handy when the module moves to the next level (already having the Javascript syntax highlighting was nice on a couple cases). I'm anxiously awaiting a go-ahead to move the code to .NET v3.5, as I think that using LINQ on the Armory files will make that stuff a breeze and the new AJAX code in .NET v3.5 is just so nice.
<Geek Off>

If you want, I can generate an SQL DDL file for the back-end to make that easier...otherwise, just do a DNN install and grab the structure from there.