Hi Luciano, Yes, this is what I was suggesting. I'm just not sure what exactly will be an AlbumAggregator, will it implement Album interface? I think there should be an AlbumDelegator that would return the right album/accessor based on a given album information (e.g. flicker url would return FlickerAlbum). The FlickerAlbum would be the accessor. An album aggregator, in my conception, would only be an Album implementation that will aggregate many albums and expose their photos through Album API. In the album aggregator scenario, I suppose it would register somewhere information about the contained albums and when loaded it would delegate each information to the AlbumDelegator, then get the right Album implementations and expose them as a single album.
Is that what you have in mind about AlbumAggregator? On Fri, Oct 29, 2010 at 3:08 PM, Luciano Resende <[email protected]>wrote: > On Fri, Oct 29, 2010 at 6:45 AM, Adriano Crestani > <[email protected]> wrote: > > The UI user should not care about where an album comes from, an > > abstract layer needs to be created which will resolve file accessing > > using some kind of AlbumAccessor implementation. Then, an accessor > > would be required for each different photo provider. If we don't > > abstract the album loading, it will get messy every time a new kind of > > photo provider is added. > > > > My 2 cents :) > > > > Agree, User wise, and API wise, you want a collection of albums > independent of where they are stored. Implementation wise, I was > proposing that they become different sub trees on the repository and > we have a AlbumAggregator which seems the same as your accessor that > would know how to do any kind of delegation and would know how to > provide a consistent view of all albums independent of it's type. Is > this in sync with what you are suggesting ? > > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
