Agree about Preference -- there will have to be some kind of object that represents an item-value pair. While the interface probably goes away, the "GenericPreference" class probably stays.
Anyone who customized a component probably has to make some non-trivial changes. People that just use standard components actually may have little or no changes. Thanks for the input, I will await more comments. I should also add that performance has become my top priority, as it always seems that the code consumes too much time and memory. So this is a large reason why I favor a change that could simplify and speed up the code and data structures, even if it means reducing flexibility slightly. Sean On Wed, Apr 22, 2009 at 1:05 PM, Andre Panisson <[email protected]> wrote: > I think removing the User and Item abstractions would be a good idea. The > User interface is a bit more complex with the getPreferences methods, but I > think it can be easily ported to the DataModel. There will be some impact in > the already written code, but I think the benefits are interesting. > I dont know if removing the Preference abstraction will bring a better > performance. The getPreferences methods are very useful to iterate over the > preferences of users and items, and I think it save a lot of lookups if the > association user/item is present in a single object. > > André
