This project is read-only.

Aftermath of 0.1.2

Feb 6, 2009 at 8:57 AM
With this latest release, I think some significant steps have been taken to improve the module's useability. There's still a lot of work to be done, so I'd like to continue hearing from everyone about possible improvements.

I think the next release (0.1.3) is going to address some long overdue cosmetic issues. Versions 0.1.1 and 0.1.2 added some depth to the data that is stored for Instances, Mobs, Raids, and Items, but nothing has really been done to reflect that data in the grids. Certainly, I'd like to add an icon link for trackback's to WowHead when applicable. I think displaying Heroic and Attendance Flags would be good as well.

In addition to displaying more in the grids, we need to better support filtering the grids. Honestly, my hesitation in this area has been for two reasons. First, I'm not exactly sure what is a good intuitive filtering mechanism, and second, I'm not exactly sure on how to code client-side setting specific stuff in a professional manner. I'll need to take some time to figure it out, since I'm pretty sure this is the way I need to go. I wouldn't expect everyone to want to filter the grids the same way, and I'd like to give the user the option on persisting their grid settings across multiple visits to the site. To do this, the filter settings would basically be stored in cookies client-side, and a user would need to clear a filter if they wanted to go back to an unfiltered view.

I've also been thinking about the Tier system, and I think I might now how to implement this while killing two birds with one stone. I think the Tier system can be implemented while moving the module more toward supporting multiple mmo's. To do this, the module and database need to be redesigned in such a way that data is stored as a configuration. An example would be that when you add the DKP module to a tab, it's basically unattached to any given database. You then go into the settings for that module instance and specify that you want this instance to be attached to soandso dataset. The database would then have to dramatically change to account for this global identifier that would unite an entire dataset of DKP into separate categories. In this way, you could have two or three instances of the DKP module in the same portal looking at different DKP datasets... kind of sounds like having multiple DKP's in one portal? Yeah, there's your multiple Tier system right there. I'm not entirely sure this is the way I want to go just yet though.

Leaderboard is still on the list, as is improving syncing tools. I think before improving sync tools, I want to see how useful the tools are in their present state. If more needs to be done to make them more intuitive, I'm sure we'll find out soon enough.
Feb 7, 2009 at 1:34 AM
This might be a stupid question, but how do you update the module without having to reinstall the module all over and without losing the current data.

DNN + Module installation = Me.Confused = True   ;)
Feb 7, 2009 at 6:31 AM
Assuming that you already have a previous version installed, all you have to do is act like you have nothing installed and install the newer version on top of the already installed old version.

Here's the deal with DNN module installations. When you install a package, that package is installed at whatever version is specified in the module's dnn configuration file. This version can later be seen in your host's module section after installation.

The version is important for one big reason, it controls which SQL scripts embedded in your package are actually executed. So take for example the DNN DKP package. If you open it up, you'll see there's 4 or 5 SQL scripts that start with some numbers. These numbers correspond to versions. If you are installing the module for the first time, all the numbered scripts will be executed in ascending order. If you are installing the package over an already installed package, the installer will only execute those scripts that are higher versions than the installed version. This is not my doing, it's the way the DNN makers made the installer.

So when you install 0.1.2 over an already installed 0.1.0, only the 0.1.1 and 0.1.2 install scripts are executed. When I write these scripts, I take this into account, and I make sure data is preserved. If you look at the actual contents of the SQL scripts, you'll notice that when I add a column or reorder a table, we make a temp in the new format, copy data over, delete the old table, and recreate triggers and constraints. It's complicated, but preserves your precious data. :)

Now, in addition to the install SQL scripts, there is an uninstall SQL script. If you delete the module from your host, that script will run.

If you open this script though, you'll see it's empty. This is because I don't want anyone to accidentally lose their data by accidentally uninstalling the module. As it is right now, you can uninstall the module, and the database will not be changed. It makes reinstalling a little complicated, but doable with some assistance.

Hope this helped.
Feb 7, 2009 at 7:48 PM
Looks to me like the installation was incomplete. ItemIcon and ItemTooltip are references to the old way of doing the mouse-over effect for item stats.

What version is your site using presently?
Feb 7, 2009 at 8:36 PM
It says it's 0.1.2
I think it did get some errors on installation, but i din't rly take notice of them.