Re: [Informa-developer] Suggestions for changes to core
Status: Beta
Brought to you by:
niko_schmuck
From: Niko S. <ni...@na...> - 2002-10-20 20:24:36
|
On Monday 14 October 2002 17:22, Jason Carreira wrote: > Niko Schmuck wrote: > > No, those are really two different concepts. CategoryIF is meant > > for being used to reflect the metadatum about what an > > item/channel is about (in the sense of the author who > > contributed the news). While ChannelGroupIF is more related for > > building up a convenient hierarchy for displaying the channels > > a user is interested in (and may be switched from user to user > > perspective), the groups must therefore totally separated from > > the original channel/item content. > > Why do we need an object for CategoryIF, if this is just the tag > given to the item by the author? Wouldn't this be better as just > a text field with the name of the category given by the author? > We aren't going to want to re-use catrgories across > authors/publishers, are we? That is exactly what I'm thinking of here, so this is perfectly fine. I want to make use of the PSI (public subject indicators) concept for categories that are used by the Topic Map paradigm. > I would also suggest that get/setTitle() be added to > ChannelGroupIF, since you'll want some way to name the groups, This may be achieved through the ID, but yes, I agree, a title property could make sense. > and adding nesting like the get/setParent(), getChildren(), and > add/removeChild() would be valuable for ChannelGroupIF, since > you'll want to be able to have hierarchical groups of channels > (at least I do). That makes also sense, although this will have some impact and break with current implementations. > >>2) Why is there an ItemMetaDataIF? Couldn't this just be rolled > >>into ItemIF? Maybe not all readers want it, is all I can > >> think... > > > > The intention was to obtain a clear separation between a news > > item intrinsics and metadata about that item. Unfortunately (on > > the programatic side) the downside is, that it does mean a bit > > longer code to gather all interesting facts for an item object > > together. If readers don't want to use it, this causes no > > headache just ignore ItemMetaDataIF (the builder cares about > > initialisation). > > Ok, I can see that. The problem is that the ItemMetaData is wired > into the Item. In a multi-user world, the item meta data is > user-specific. Different users may have different strategies for > scoring items, and will definitely want different values for > isMarkedRead(). Yes, that point is clear, for such environment I would suggest to not use the ItemMetaData but plug-in your own solution for the time being, I'm sorry this will need some time to make it into informa. > >> 4) Maybe it's just me, but Informa seems too single-user only. > >> I think we need a UserIF, Categories need to be owned by a > >> user, and ChannelBuilderIF needs to create categories, etc. > >> for one user.. > > > > Very good point (to introduce UserIF), while I don't agree that > > the user should assign categores (see my notes on 1). I have to > > think more about the implications, though. If you would > > elaborate more on your multi-user idea, this could defn help. > > I want to have a (potentially) multi-user app, with different > settings for each user. Each user can have their own > subscriptions, altough the app will maintain a single set of all > of the channels and items. When a user wants to add a channel > subscription, they can either choose one of the channels already > being loaded by the app, or add a new one. When users > unsubscribe, if no-one else is subscribed, then the channel is > de-activated. > > Each user should also have their own meta-data about channels and > items, such as the last time the channel was read, the item score > and read status. Thanks for the details, that sounds very interesting, what kind of application are you developing exactly? Will it be somehow be available? Is it open source? > Here's another one for you. I think the ChannelBuilderIF should > be pared down to just what the ChannelParser needs, with > ChannelGroup [...] No, this would break absolutely from the way we want to access different storage implementations (like we have no the in-memory and Castor JDO one). The point is here, to have something like a channel provider factory which gives you back implementation specific variants. Niko |