Re: SilvaNews-1.0 bugs/questions

Marc and Guido,

Thanks for your responses!  Marc, I'll comment on your service_news thoughts 
when I get to it below:

> To be honest the reason the item is in the add list is most probably
> because Zope just does that, if you register a content type to Zope
> there is (afaik) no common way to make it not appear in that list.

If no silva objects (besides the silva root, of course) should be added via 
the ZMI, I wonder if their ZMI add scripts should be replaced with a page 
that says: "Use the SMI to add this!"  If the "news publication" type had 
something like this, at least it wouldn't be seen as a bug.

> However, you should never add a Silva content type through the SMI
> (read: a content type that you can add in the SMI too) since it may not
> get properly registered to Silva that way.
I haven't had problems adding through the ZMI before, but I see your point ;-)

> That's a bug, I'll fix it in the next release. Contrary to what Marc
> Petitmermet says, this will be the way to structure news publications
> for now, perhaps we may want to think it over later.
I think it makes sense to structure news publications in this way.  Since 
you're prob. using news viewers on the public side, this structuring doesn't 
really affect the public side, but it does make it easier to manage news 
items.  I could also see a News Publication being a BTreeFolder, and letting 
you search for the news items you want (e.g. displaying all the audiences and 
subjects along with a date range, version, etc).  There are advantages to 
that, but then you run the possibility of 'loosing' a news item if all the 
audiences and subjects which were attributed to it were deleted.
>
> but I would like to ask you something first: how do you 
> like the setup of the product?
> The reason why I'm asking this is that most people seem to think 
> SilvaNews is overly complex, the current setup may allow filtering but
> it looks like users don't easily get a grip on it and it has been
> suggested to take a completely different, far simpler approach a couple
> of times. What's your thought on this?

To be honest, I felt it was complex the first time I looked at it as well (and 
I'm a developer!).  But now that I understand how it works, I see the power 
in the design, and appreciate it.  I haven't used SilvaNews for anything yet 
besides that custom newsletter I wrote (which only uses one Silva 
Publication).  So here's a thought on simplification:  doing away with the 
filters, and merge that functionality into the News Viewers?  Inside the news 
viewer, you could have a separate tab to choose the new publications and 
subjects/audiences you're pulling from.

I do plan on using News Filters in my implementation, but I think these 
filters certainly add complexity, especially if you're either evaluating the 
product with a small set of news items or only wish to use it with one news 
publication (think small business).  For a university, government, or other 
large non-profit, I see these filters as being very useful, because you have 
the flexibility to have a very distributed news system (which I like).

One news cms approach I saw recently (which is used for Indiana State 
University in the US) expands the subjects and target audiences a bit.  For 
this university, there were easily 100+ subjects and 100+ audiences (and 
associate news items with a faculty member).  When adding a news item, you 
can see how that number of choices can be rather daunting/annoying.  

With this distributed news system, I really like Marcs idea of news objects 
acquiring the nearest service_news to pull the audiences and subjects from.  
However, you'd want to make sure audiences and subjects can be selectively 
acquired from higher service_news objects.  Or, if each news publication had 
a service_news like tab, where you could manage that publications s/a's.  In 
that case, it would be nice to store EVERY sub. and aud. in the master 
service_news so other news publications not necessarily in the acquisition 
tree can use the same subs and auds.

Thinking long-term, audiences and subjects will change.  But if you're 
archiving your news, it would be nice to retain the old categories.  If the 
service_news was able to archive categories as well, that'd be neat!

Guido, would you like me to send my service_news that has titles in the subs 
and auds (it's for 0.9.3, not 1.0)?

Cheers,
Andy

>
> Cheers,
>
> Guido