Okay, the final spots in the code that were not obeying guild preferences for date formatting are gone, gone, gone. Enjoy.
- New page for just viewing guild logs, for those who are into that sort of thing.
- No more spurious "admin message changed" logs for characters
- Fixed a javascript bug that kept some logs from showing
- Bulk gear changes now create log entries
Okay, one caveat:
If you were to, say, rename "Aegis of the Argent Crusade" to "Aegis of the Argent Crusa", you'd see log entries for each drop showing the drop had been changed. That's all well and good.
When the item scanner comes through and tries to find your item, it's going to change "Argent Crusa" to "Argent Crusade". So your previous change would be worthless. If this is the case, those log entries will be deleted. Whoosh. Gone.
Try not to panic. Everything is under control.
Wednesday, December 17, 2008
Dates and you
Okay, Aussies. You got your wish.
Time and date formats are now (somewhat) customizable. Set it up in the Guild Control Panel.
If there are formats you would like that are not in the list, let me know.
There are a couple of pages that have old date formatting. That'll be going away real soon now.
Time and date formats are now (somewhat) customizable. Set it up in the Guild Control Panel.
If there are formats you would like that are not in the list, let me know.
There are a couple of pages that have old date formatting. That'll be going away real soon now.
Small requested feature
The item scanner is far more flexible now. Means you should start seeing icons and info faster...since I'm not having to do as many manual changes anymore.
Also on the new list: if a character has been on a run in the last 30 days, they'll show up in the active list even if inactive. Much easier to keep track of people, says I.
Also on the new list: if a character has been on a run in the last 30 days, they'll show up in the active list even if inactive. Much easier to keep track of people, says I.
Sunday, December 14, 2008
A week of small changes
Only two tables left now in the entire system using the old dynamic tables. Rendering is now much faster - not seeing near as many multi-second page render times.
Coming up next: per-pool character listings. This should be the last feature needed before multi-priorities come in. Multi-priorities are where we might take into consideration, say, rank before DKP. Or attendance might be a factor.
Along with multi-priorities will come a rework of the pools and events page. Right now it's pretty confusing (as in there's next to no data whatsoever). I'm looking to create a page that will walk you through basic decisions about DKP so first-timers have a better time of it.
Oh, and give people the ability to actually delete events. That'd be nice.
Coming up next: per-pool character listings. This should be the last feature needed before multi-priorities come in. Multi-priorities are where we might take into consideration, say, rank before DKP. Or attendance might be a factor.
Along with multi-priorities will come a rework of the pools and events page. Right now it's pretty confusing (as in there's next to no data whatsoever). I'm looking to create a page that will walk you through basic decisions about DKP so first-timers have a better time of it.
Oh, and give people the ability to actually delete events. That'd be nice.
Tuesday, December 9, 2008
More better faster
So I finally sat down and got all the new dynamic table stuff ready. The technique that sped up the guild front page so much about a month ago has been applied to the character detail page as well as the run editor's log viewer.
So far it's brought the slowest loading page on the site down from 3.5 seconds (ouch!) to around 0.3 seconds. I think that's workable.
For those who are interested in this sort of thing: I have a small aversion to AJAX. When possible, I prefer to render things remotely: my tools are better, my debugging's better, all that sort of thing. I think this stood me in good stead when it came to the original version of AJAX (hardly anyone seems to use the XSLT variety anymore) and isn't a bad first instinct.
But when you have a page with multiple data tables that you want to paginate separately, you start having to do silly things to use remote rendering (said silly things mostly relating to out-of-band data for things like pagination), and the remote rendering starts taking a long time. Enter JSON. I wrote some javascript to populate a table from JSON data and we were off to the races. Most of the rendering is still done on the Swagbook server, but Swagbook now sends prettified components to the browser, which then assembles the table.
So what's the downside? Well, now javascript changes every time I want to change up a table - which doesn't happen as often as I'd thought it might. There's also an annoying "pop" as the page loads - this is from the second HTTP request for the JSON data. I'm considering eliminating the pop for some pages by stuffing the default data in the bottom of the page, but it's a bit low on the priority list right now.
So far it's brought the slowest loading page on the site down from 3.5 seconds (ouch!) to around 0.3 seconds. I think that's workable.
For those who are interested in this sort of thing: I have a small aversion to AJAX. When possible, I prefer to render things remotely: my tools are better, my debugging's better, all that sort of thing. I think this stood me in good stead when it came to the original version of AJAX (hardly anyone seems to use the XSLT variety anymore) and isn't a bad first instinct.
But when you have a page with multiple data tables that you want to paginate separately, you start having to do silly things to use remote rendering (said silly things mostly relating to out-of-band data for things like pagination), and the remote rendering starts taking a long time. Enter JSON. I wrote some javascript to populate a table from JSON data and we were off to the races. Most of the rendering is still done on the Swagbook server, but Swagbook now sends prettified components to the browser, which then assembles the table.
So what's the downside? Well, now javascript changes every time I want to change up a table - which doesn't happen as often as I'd thought it might. There's also an annoying "pop" as the page loads - this is from the second HTTP request for the JSON data. I'm considering eliminating the pop for some pages by stuffing the default data in the bottom of the page, but it's a bit low on the priority list right now.
Thursday, December 4, 2008
I'll cry. Oh yes. You just sit there and I'll start the tears.
I'm happy Swagbook is being used. Not so happy about bugs.
But the interface to Wowhead is back up and running. They took down their old interface that would have easy XML output for searches, but it's working now.
Oh, and I discovered that timezone caching wasn't working. It is now. Pages with dates on them should be MUCH faster. Shaved about 20% off the load time of the run list, for example.
You keep using it, I'll keep fixing it.
But the interface to Wowhead is back up and running. They took down their old interface that would have easy XML output for searches, but it's working now.
Oh, and I discovered that timezone caching wasn't working. It is now. Pages with dates on them should be MUCH faster. Shaved about 20% off the load time of the run list, for example.
You keep using it, I'll keep fixing it.
Subscribe to:
Posts (Atom)