I'm still inclined to not include this in official Ansel code.  It's a 
good idea for improving performance in a very specific use case, but 
using class wrappers, or even another static function to get 
information we already have a nice API to deal with still seems a bit 
hackish to me.

If the classes will do it themselves, loading the owner prefs will be 
needed - as now. The wrap prevents object creation and pref db access. 
If you wont I can create a static function to get the names instead of 
wrapping objects if you think it will be cleaner.

I agree, this is really an ugly hack.

While I understand what your trying to do here, and I agree with the 
idea - wouldn't something like this be best handled in the respective 
Prefs / Identities classes themselves instead of having to wrap them 
in every application that would want to access them?



Any one else have any thoughts on this?

slightly better

In a public community logic users, as this is their virtual life, 
identifies them-self with their nicknames. So wrap users 
identities/preferences to not load other users preferences if values 
are locked, as will always be empty and we always display  "only" the 
"Username" od "User's gallery". This will save even who additional 
queries for every different user in gallery list (one for Horde one 
for Ansel, up to 18 if listing 9 galleries from other users).