Mailing List Archive

----- Original Message -----
From: "Timothy Wilson" <wilson@visi.com>
To: <zope-ptk@zope.org>
Sent: Tuesday, February 15, 2000 2:38 PM
Subject: [Zope-PTK] feature request: news categories


> I would like the PTK-based news product to be more Slashdot-like.

Butch has a number of interesting thoughts for Squishdot in a PTK-world. I
think he's talked about some on this list.

> To make our site truly awesome, we'd also need:
>
> * the ability to assign certain reviewers to certain categories
> * potentially, (although this could be handled by reviewers) the ability
> to restrict users to posting in certain categories.
>
> At this point, and I'm stretching my Zope Zen a bit at this point, I've
> been planning to subclass the PTK-News class to provide the extra
> category stuff. Is this a reasonable approach? At the same time, I think
> that there would be others who would be interested in news categories for
> portals that lack the singular focus of Zope.org.

I'm definitely interested in categories. Actually, I wonder what happened to
the original Topics idea that Amos had started up.

I think having some notion of categories at the heart of the PTK makes
sense. It may be possible to implement a categorization system by making a
Folder and role for each category and then setting access appropriately.
Maybe that's even the "right" way to do it, because you get the full
flexibility of the Zope security machinery, and you can still use Catalog to
give global views of the information.

Kevin

Hi Kevin,

At 14:59 Uhr -0500 15.02.2000, Kevin Dangoor wrote:
> > I would like the PTK-based news product to be more Slashdot-like.
>
>Butch has a number of interesting thoughts for Squishdot in a PTK-world. I
>think he's talked about some on this list.

How about a PTK version of KM|net news? This is a great product from
you and would defenitely be an interesting addition to the PTK.

Remeber you said you will defenitely provide an upgrade path to PTK -
that's probably the best way...

Imagine every user being able to submit articles for every news
category and all the whistle and bells of KM|net news.... Top stories
for the homePage, rankings, favorites... and later the customizing
features for every user: create your own portal newspage, select the
categories you'r most interested in and those Top-Stories will be
your homepage... ahh, great!!!!

Jochen

Hi,

I too am very interested in categories. When you talk about
subclassing the News object below and using folder do you
mean that the object would be stored in this folder?

The present PTK keeps all objects in the authors members folder or
children. I do not know if this is by design or just present
convenience. It does seem to simplify security and the review/
publishing mechaism seems to allow for managed publishing.

I am new to Zope and cannot yet figure out how to create an
object in another folder and set the correct permissions. I was
able to subclass the portal document object and add category
fields (properties). I am now struggling with trying to enter
this category property in the Catalog as a Keyword Field.

Then to simulated category lookup I would like to create
a search query that returns just items of a certain category.
It looks like the PTK wrapper around Zcatalog will ensure that
only authenticated users can see non-public items. The big problem
I have now is finding the syntax for getCatalog().searchResults(....)
to give me just the items with the keyWorks I want.

To automate the management and generation of the KeyWords, I was
going to use a "tree" of folders that have titles that match the
KeyWords. Then, using acquisition one query method would parse
the branches of the tree up to root and have the KeyWords. The
"tree" of keywords would be a hierarchical oncology of topics
hosted by this site. Adding a new topic is just adding a new
folder to the tree. Then a compact version of this tree needs to
be available to the user in the add and edit forms of the object
to ensure that correct KeyWords are used.

This is likely a ugly hack of an approach but, it fits in my feeble
mind and I can see the steps to complete it if I start getting
some help from the list ;).

Best,

Chip

>-----Original Message-----
>From: zope-ptk-admin@zope.org [mailto:zope-ptk-admin@zope.org]On Behalf
>Of Kevin Dangoor
>Sent: Tuesday, February 15, 2000 11:59 AM
>To: Timothy Wilson; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] feature request: news categories
>
>
>----- Original Message -----
>From: "Timothy Wilson" <wilson@visi.com>
>To: <zope-ptk@zope.org>
>Sent: Tuesday, February 15, 2000 2:38 PM
>Subject: [Zope-PTK] feature request: news categories
>
>
>> I would like the PTK-based news product to be more Slashdot-like.
>
>Butch has a number of interesting thoughts for Squishdot in a
>PTK-world. I
>think he's talked about some on this list.
>
>> To make our site truly awesome, we'd also need:
>>
>> * the ability to assign certain reviewers to certain categories
>> * potentially, (although this could be handled by reviewers)
>the ability
>> to restrict users to posting in certain categories.
>>
>> At this point, and I'm stretching my Zope Zen a bit at this
>point, I've
>> been planning to subclass the PTK-News class to provide the extra
>> category stuff. Is this a reasonable approach? At the same
>time, I think
>> that there would be others who would be interested in news
>categories for
>> portals that lack the singular focus of Zope.org.
>
>I'm definitely interested in categories. Actually, I wonder
>what happened to
>the original Topics idea that Amos had started up.
>
>I think having some notion of categories at the heart of the PTK makes
>sense. It may be possible to implement a categorization system
>by making a
>Folder and role for each category and then setting access
>appropriately.
>Maybe that's even the "right" way to do it, because you get the full
>flexibility of the Zope security machinery, and you can still
>use Catalog to
>give global views of the information.
>
>Kevin
>
>
>_______________________________________________
>Zope-PTK maillist - Zope-PTK@zope.org
>http://lists.zope.org/mailman/listinfo/zope-ptk
>
>

Hi, Jochen

----- Original Message -----
From: "Jochen Haeberle" <listen@MIDRAS.de>
To: "Kevin Dangoor" <kid@kendermedia.com>
Cc: <zope-ptk@zope.org>
Sent: Tuesday, February 15, 2000 6:54 PM
Subject: Re: [Zope-PTK] feature request: news categories


> At 14:59 Uhr -0500 15.02.2000, Kevin Dangoor wrote:
> > > I would like the PTK-based news product to be more Slashdot-like.
> >
> >Butch has a number of interesting thoughts for Squishdot in a PTK-world.
I
> >think he's talked about some on this list.
>
> How about a PTK version of KM|net news? This is a great product from
> you and would defenitely be an interesting addition to the PTK.

From some conversations with Butch a couple weeks back, I wouldn't be
surprised to see KM|Net News and Squishdot merge. Though today they are very
different in implementation and feel, I think it's possible that a single
Product could serve both needs well.

> Remeber you said you will defenitely provide an upgrade path to PTK -
> that's probably the best way...

There will be an upgrade path for sure. We've got more than 150 articles in
our KMNN now, and I'm not going to manually re-enter them :)

> Imagine every user being able to submit articles for every news
> category and all the whistle and bells of KM|net news.... Top stories
> for the homePage, rankings, favorites... and later the customizing
> features for every user: create your own portal newspage, select the
> categories you'r most interested in and those Top-Stories will be
> your homepage... ahh, great!!!!

There are indeed some great possibilities! Imagine those features you like
about KMNN and add the ability to have discussions attached to the articles,
if you wish... That's kind of what I'm seeing for the future (plus all of
the great customization and review stuff that PTK will enable).

Kevin

----- Original Message -----
From: "Chip Vanek" <chip@upcast.com>
To: <zope-ptk@zope.org>
Sent: Tuesday, February 15, 2000 6:59 PM
Subject: RE: [Zope-PTK] feature request: news categories


> I too am very interested in categories. When you talk about
> subclassing the News object below and using folder do you
> mean that the object would be stored in this folder?
>
> The present PTK keeps all objects in the authors members folder or
> children. I do not know if this is by design or just present
> convenience. It does seem to simplify security and the review/
> publishing mechaism seems to allow for managed publishing.

It's true that the present PTK keeps objects in the members' folders, but it
doesn't *have* to be that way for all things. While that arrangement works
well for Zope.org, I think there will be lots of portalish sites where
things will make more sense in a centralized place.

In truth, I haven't really given much thought to the idea of storing the
items within folders named for the categories. As far as delegation of
responsibility and configuring security based on categories goes, it seems
like that would work very nicely with a minimum of fuss (read: custom code).

The thing I really don't like about putting the items within a folder based
on category is that it is quite conceivable that you may want to reorganize
items into different categories down the line. If that happens, the URLs of
your articles change. I'm a big proponent of having URLs be stable for as
long as possible. (Once they're in a search engine, it's nice if they keep
working.)

> I am new to Zope and cannot yet figure out how to create an
> object in another folder and set the correct permissions. I was
> able to subclass the portal document object and add category
> fields (properties). I am now struggling with trying to enter
> this category property in the Catalog as a Keyword Field.

The key to putting an object in another Folder is that you've got to have
permission to create that kind of object in that Folder. If you want the
ability for a user to add something without having that permission
themselves, you use a "proxy role". This is what KM|Net News does. The
AddArticle method has a proxy role of Manager, so anyone can add an article
using that method.

> Then to simulated category lookup I would like to create
> a search query that returns just items of a certain category.
> It looks like the PTK wrapper around Zcatalog will ensure that
> only authenticated users can see non-public items. The big problem
> I have now is finding the syntax for getCatalog().searchResults(....)
> to give me just the items with the keyWorks I want.

ZCatalog is generally pretty easy to use. There is some good information in
the HowTos on Zope.org. I haven't looked at it in the context of the PTK
yet. You would probably do something like:

<dtml-in "searchResults({'category' : ['Category1', 'Category2']})">

would probably let you search for those two categories...

> To automate the management and generation of the KeyWords, I was
> going to use a "tree" of folders that have titles that match the
> KeyWords. Then, using acquisition one query method would parse
> the branches of the tree up to root and have the KeyWords. The
> "tree" of keywords would be a hierarchical oncology of topics
> hosted by this site. Adding a new topic is just adding a new
> folder to the tree. Then a compact version of this tree needs to
> be available to the user in the add and edit forms of the object
> to ensure that correct KeyWords are used.

This sounds similar to the Topics proposal that Amos posted to the Zope.org
site a couple months back. The difference is that the Topics proposal was
completely Catalog driven. So, you could have a hierarchy of items without
regard to where they sit in the ZODB.

Kevin

>-----Original Message-----
>From: Kevin Dangoor [mailto:kid@kendermedia.com]
>Sent: Tuesday, February 15, 2000 6:20 PM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] feature request: news categories
>
>
>
>----- Original Message -----
>From: "Chip Vanek" <chip@upcast.com>
>To: <zope-ptk@zope.org>
>Sent: Tuesday, February 15, 2000 6:59 PM
>Subject: RE: [Zope-PTK] feature request: news categories
>
>
>> I too am very interested in categories. When you talk about
>> subclassing the News object below and using folder do you
>> mean that the object would be stored in this folder?
>>
>> The present PTK keeps all objects in the authors members folder or
>> children. I do not know if this is by design or just present
>> convenience. It does seem to simplify security and the review/
>> publishing mechaism seems to allow for managed publishing.
>
>It's true that the present PTK keeps objects in the members'
>folders, but it
>doesn't *have* to be that way for all things. While that
>arrangement works
>well for Zope.org, I think there will be lots of portalish sites where
>things will make more sense in a centralized place.
>
>In truth, I haven't really given much thought to the idea of
>storing the
>items within folders named for the categories. As far as delegation of
>responsibility and configuring security based on categories
>goes, it seems
>like that would work very nicely with a minimum of fuss (read:
>custom code).
>
>The thing I really don't like about putting the items within a
>folder based
>on category is that it is quite conceivable that you may want
>to reorganize
>items into different categories down the line. If that
>happens, the URLs of
>your articles change. I'm a big proponent of having URLs be
>stable for as
>long as possible. (Once they're in a search engine, it's nice
>if they keep
>working.)
>
I very much agree with your comment about URL stability. I kind
of like the present PTK way because the author of the information
has the items local to them. Now when these people leave or are
aged off the system the problems begin. These could be moved to
a central archive and redirects added as part of the user delete
process.

I liked content stating in a users home folder, partially because of
my inability to yet figure out how to safely write a file remote
folder and partially because I liked the idea of authors owning
their output. The catalog seems like a reasonable way to find
all the items wereever they are on the site, assuming it scales.

>> I am new to Zope and cannot yet figure out how to create an
>> object in another folder and set the correct permissions. I was
>> able to subclass the portal document object and add category
>> fields (properties). I am now struggling with trying to enter
>> this category property in the Catalog as a Keyword Field.
>
>The key to putting an object in another Folder is that you've
>got to have
>permission to create that kind of object in that Folder. If
>you want the
>ability for a user to add something without having that permission
>themselves, you use a "proxy role". This is what KM|Net News does. The
>AddArticle method has a proxy role of Manager, so anyone can
>add an article
>using that method.

That makes sense but dosn't the object take on the proxy role as
creator? Can the original author still edit it?


>
>> Then to simulated category lookup I would like to create
>> a search query that returns just items of a certain category.
>> It looks like the PTK wrapper around Zcatalog will ensure that
>> only authenticated users can see non-public items. The big problem
>> I have now is finding the syntax for getCatalog().searchResults(....)
>> to give me just the items with the keyWorks I want.
>
>ZCatalog is generally pretty easy to use. There is some good
>information in
>the HowTos on Zope.org. I haven't looked at it in the context
>of the PTK
>yet. You would probably do something like:
>
><dtml-in "searchResults({'category' : ['Category1', 'Category2']})">
>
>would probably let you search for those two categories...

I have read all the HowTos and guides many times. I actually built
a list of parents that essentually became the list of category keys
and have tried a syntax like that. Shown below:

searchResults('ZcatKeyField' in ListVar)

I also tried your secret voodoo syntax with curly brackets and :

That got me the error trace below:

<!--
Traceback (innermost last):
File C:\JPLAT\zope\lib\python\ZPublisher\Publish.py, line 214, in
publish_module
File C:\JPLAT\zope\lib\python\ZPublisher\Publish.py, line 179, in publish
File C:\JPLAT\zope\lib\python\Zope\__init__.py, line 202, in
zpublisher_exception_hook
(Object: ElementWithAttributes)
File C:\JPLAT\zope\lib\python\ZPublisher\Publish.py, line 165, in publish
File C:\JPLAT\zope\lib\python\ZPublisher\mapply.py, line 160, in mapply
(Object: showTopics)
File C:\JPLAT\zope\lib\python\ZPublisher\Publish.py, line 102, in
call_object
(Object: showTopics)
File C:\JPLAT\zope\lib\python\OFS\DTMLMethod.py, line 145, in __call__
(Object: showTopics)
File C:\JPLAT\zope\lib\python\DocumentTemplate\DT_String.py, line 502, in
__call__
(Object: showTopics)
File C:\JPLAT\zope\lib\python\DocumentTemplate\DT_In.py, line 633, in
renderwob
(Object: getCatalog().searchResults({'Topic_keys' : tkeys}))
File C:\JPLAT\zope\lib\python\DocumentTemplate\DT_Util.py, line 335, in
eval
(Object: getCatalog().searchResults({'Topic_keys' : tkeys}))
(Info: tkeys)
File &lt;string&gt;, line 0, in ?
File C:\JPLAT\zope\lib\python\Products\PTKBase\PortalCatalog.py, line 44,
in searchResults
(Object: ElementWithAttributes)
AttributeError: AUTHENTICATED_USER

Also with explicit values in list:

File C:\JPLAT\zope\lib\python\DocumentTemplate\DT_Util.py, line 335, in eval
(Object: getCatalog().searchResults({'Topic_keys' : ['Markets',
'Americas']}))
(Info: getCatalog)
File &lt;string&gt;, line 0, in ?
File C:\JPLAT\zope\lib\python\Products\PTKBase\PortalCatalog.py, line 44,
in searchResults
(Object: ElementWithAttributes)
AttributeError: AUTHENTICATED_USER
>
>> To automate the management and generation of the KeyWords, I was
>> going to use a "tree" of folders that have titles that match the
>> KeyWords. Then, using acquisition one query method would parse
>> the branches of the tree up to root and have the KeyWords. The
>> "tree" of keywords would be a hierarchical oncology of topics
>> hosted by this site. Adding a new topic is just adding a new
>> folder to the tree. Then a compact version of this tree needs to
>> be available to the user in the add and edit forms of the object
>> to ensure that correct KeyWords are used.
>
>This sounds similar to the Topics proposal that Amos posted to
>the Zope.org
>site a couple months back. The difference is that the Topics
>proposal was
>completely Catalog driven. So, you could have a hierarchy of
>items without
>regard to where they sit in the ZODB.
>

I am still only weeks in Zope land and have not read much beyond
guides and HowTos (plus some interesting mail from this list;).

I think the direction I am going is also very dependent on the
Catalog. The items will stay in the home folder of the authors
and the sole purpose of the folder hierarchy is to provide a simple
visual metaphor for browsing the categories. Then you can use the
tree tag, aquisition, and a simple to maintain structure to view,
use, and edit the categories.

Anyway thanks for the reply and if you have any ideas about some new
searchResults syntax, let me know.

Chip

>Kevin
>
>

At 20:12 Uhr -0500 15.02.2000, Kevin Dangoor wrote:
> > How about a PTK version of KM|net news? This is a great product from
> > you and would defenitely be an interesting addition to the PTK.
>
From some conversations with Butch a couple weeks back, I wouldn't be
>surprised to see KM|Net News and Squishdot merge. Though today they are very
>different in implementation and feel, I think it's possible that a single
>Product could serve both needs well.

Ah? This really sounds a bit strange to me... although both are
somehow based on news and articles, I see their target really
different. Squishdot stresses on a community while KMNN is more of an
online newspaper...

> > Remeber you said you will defenitely provide an upgrade path to PTK -
> > that's probably the best way...
>
>There will be an upgrade path for sure. We've got more than 150 articles in
>our KMNN now, and I'm not going to manually re-enter them :)

:) I see... I am very interested to see what that will look like!

> > Imagine every user being able to submit articles for every news
> > category and all the whistle and bells of KM|net news.... Top stories
> > for the homePage, rankings, favorites... and later the customizing
> > features for every user: create your own portal newspage, select the
> > categories you'r most interested in and those Top-Stories will be
> > your homepage... ahh, great!!!!
>
>There are indeed some great possibilities! Imagine those features you like
>about KMNN and add the ability to have discussions attached to the articles,
>if you wish... That's kind of what I'm seeing for the future (plus all of
>the great customization and review stuff that PTK will enable).

I had no problem at all adding ZDiscussions to my articles - I guess
thanks to your help with the DTML :) I even have an easy interface
for the reviewer to add one - I attached that to the article
review-page. It either shows a link "add a discussion to this
article" or if one exists "review discussion entries". As the KMNN
articles are object containers I just droped the discussion in there
- it was very easy to handle.
I had problems adding polls this way. For whatever reason the polls
always were created in the root-folder, outside of the Article store.

I too am very excited about the customization features awaiting us
with PTK! Nevertheless, for the sites I am builing I am more in need
for KMNN than for Squishdot :-)

>Kevin

Jochen

Hi again Kevin!

At 21:20 Uhr -0500 15.02.2000, Kevin Dangoor wrote:
>The thing I really don't like about putting the items within a folder based
>on category is that it is quite conceivable that you may want to reorganize
>items into different categories down the line. If that happens, the URLs of
>your articles change. I'm a big proponent of having URLs be stable for as
>long as possible. (Once they're in a search engine, it's nice if they keep
>working.)

Absolutely! This is a very great feature of Zope and KMNN in
particular. Search engine presence is so important for content driven
sites! I don't really understand why it seems that no one makes
intensive use of this. Heck, you even have transitional
ZSQL-Methods!!!

On the other hand, there is no thing out there handling automatic
generation of header meta-tags (I will add this to my KMNN soon, as
the first site finishes and is going to search engines, the
description tag for example will be the first part of the teaser,
keywords are to be entered separately, author, copyright,...)
And there's this naming sheme index_html, there are search engines
that will ignore everything not ending in .html or .htm because they
suspect dynamic creation!

For a KMNN or eveen a PTK site, it seems important to ensure that the
main page is not indexed but all the linked and static pages are. This
works fine with KMNN by putting a robots-tag no-index, follow in the
head of the start & actual-pages and robot index, follow in all
other, rather static pages. The actual and archive pages will enable the
robots to get all the articles over time. With the present PTK, the
DemoPortal, it is not that clear how this will work. A spider can't use
the search-button...

This is why I would so much like to see a KMNN implementation for
PTK, well I am concentrating on those newssites at the moment as I
think that most corporate sites could benefit from that point of view
also!

Jochen

Chip Vanek wrote:
> I too am very interested in categories. When you talk about
> subclassing the News object below and using folder do you
> mean that the object would be stored in this folder?

Long thread...sorry for the delay in replying.

> The present PTK keeps all objects in the authors members folder or
> children. I do not know if this is by design or just present
> convenience. It does seem to simplify security and the review/
> publishing mechaism seems to allow for managed publishing.

Just like Zope.org, content can be anywhere. But giving people a
"me-centric" view of their content is powerful.

I don't buy the argument that putting stuff close to people breaks
URLs. Take a look on the web at all the ~username URLs you see out
there. Moreover, deleting a member doesn't delete their content, just
like deleting someone on a Linux system doesn't delete all their files.

Regarding the idea of folders based on categories, this is precisely
what Topics are to do, with the advantage that the same item can appear
in *many* places. A Topic is like a folder where most of the items come
from a catalog lookup.

Note, thought, that the items aren't _really_ in the folder. When you
click to visit the item, it goes to the real URL. Perhaps that's not
what you want.

> I am new to Zope and cannot yet figure out how to create an
> object in another folder and set the correct permissions. I was
> able to subclass the portal document object and add category
> fields (properties). I am now struggling with trying to enter
> this category property in the Catalog as a Keyword Field.

Hmm, are you saying you can't create a Portal Folder, then create stuff
in there?

> Then to simulated category lookup I would like to create
> a search query that returns just items of a certain category.
> It looks like the PTK wrapper around Zcatalog will ensure that
> only authenticated users can see non-public items. The big problem
> I have now is finding the syntax for getCatalog().searchResults(....)
> to give me just the items with the keyWorks I want.

Yep, that's an issue.

> To automate the management and generation of the KeyWords, I was
> going to use a "tree" of folders that have titles that match the
> KeyWords. Then, using acquisition one query method would parse
> the branches of the tree up to root and have the KeyWords. The
> "tree" of keywords would be a hierarchical oncology of topics
> hosted by this site. Adding a new topic is just adding a new
> folder to the tree. Then a compact version of this tree needs to
> be available to the user in the add and edit forms of the object
> to ensure that correct KeyWords are used.
>
> This is likely a ugly hack of an approach but, it fits in my feeble
> mind and I can see the steps to complete it if I start getting
> some help from the list ;).

Hopefully Topics will help this. I'll check on the ETA for Topics.

--Paul

At 9:07 Uhr -0500 16.02.2000, Paul Everitt wrote:
>Chip Vanek wrote:
> > I too am very interested in categories. When you talk about
> > subclassing the News object below and using folder do you
> > mean that the object would be stored in this folder?
>
>Long thread...sorry for the delay in replying.
>
> > The present PTK keeps all objects in the authors members folder or
> > children. I do not know if this is by design or just present
> > convenience. It does seem to simplify security and the review/
> > publishing mechaism seems to allow for managed publishing.
>
>Just like Zope.org, content can be anywhere. But giving people a
>"me-centric" view of their content is powerful.

I think this depends... for content like that on Zope.org, that's
perfect. But if you think of some sort of news system, than providing
an article is more of "submitting" it to the editor of the paper. I
think this is important that the user does not have every control of
the article as publishing rights get handed over to the paper... and
if the content "moves" out of the users folder when it is sent to
review, that's a sign of that legal event.

>I don't buy the argument that putting stuff close to people breaks
>URLs. Take a look on the web at all the ~username URLs you see out
>there. Moreover, deleting a member doesn't delete their content, just
>like deleting someone on a Linux system doesn't delete all their files.

I guess it would be possible to find means to secure this... ID's
need not be editable after all...

On the other hand, when using search engines or link lists, you know
how much content on the Internet changes. The people on this list
might be aware of those problems, but most users we will deal with in
the Portals defenitely are not!

Jochen

Jochen Haeberle wrote:
> I think this depends... for content like that on Zope.org, that's
> perfect. But if you think of some sort of news system, than providing
> an article is more of "submitting" it to the editor of the paper. I
> think this is important that the user does not have every control of
> the article as publishing rights get handed over to the paper... and
> if the content "moves" out of the users folder when it is sent to
> review, that's a sign of that legal event.

Who said that reviewing policies were tied to location? Who said the
user would suddenly get every control of the article?

> >I don't buy the argument that putting stuff close to people breaks
> >URLs. Take a look on the web at all the ~username URLs you see out
> >there. Moreover, deleting a member doesn't delete their content, just
> >like deleting someone on a Linux system doesn't delete all their files.
>
> I guess it would be possible to find means to secure this... ID's
> need not be editable after all...
>
> On the other hand, when using search engines or link lists, you know
> how much content on the Internet changes. The people on this list
> might be aware of those problems, but most users we will deal with in
> the Portals defenitely are not!

You seem to argue, "Don't let users author anything, because they might
change it, and thus break search engines." You can certainly have a
portal where members aren't allowed to author anything.

There is no reason to think that putting content in a central place will
magically solve all problems regarding change.

At the end of the day, though, please remember: it's just like HTML
files on websites. You can put them in your home directory, or if the
local policies require that you put them in a central area, you can do
that as well.

I'm still confused as to what is the problem here. What does the PTK
not do that it should? It lets you put the same kind of content in
central folders, with the same policies, as in member folders. Should
it do something different when content goes in a central folder?

--Paul

Chip Vanek wrote:
> I very much agree with your comment about URL stability. I kind
> of like the present PTK way because the author of the information
> has the items local to them. Now when these people leave or are
> aged off the system the problems begin. These could be moved to
> a central archive and redirects added as part of the user delete
> process.

Why? If you delete the member, the member folder is still there.

> I liked content stating in a users home folder, partially because of
> my inability to yet figure out how to safely write a file remote
> folder and partially because I liked the idea of authors owning
> their output. The catalog seems like a reasonable way to find
> all the items wereever they are on the site, assuming it scales.

Right.

> >The key to putting an object in another Folder is that you've
> >got to have
> >permission to create that kind of object in that Folder. If
> >you want the
> >ability for a user to add something without having that permission
> >themselves, you use a "proxy role". This is what KM|Net News does. The
> >AddArticle method has a proxy role of Manager, so anyone can
> >add an article
> >using that method.
>
> That makes sense but dosn't the object take on the proxy role as
> creator? Can the original author still edit it?

I assume that will be the dominant pattern, though it doesn't have to
be. Lotus Notes has a built-in role for people that can create things,
but not edit/update them.

--Paul

----- Original Message -----
From: "Paul Everitt" <paul@digicool.com>
To: "Jochen Haeberle" <listen@MIDRAS.de>
Cc: <zope-ptk@zope.org>
Sent: Wednesday, February 16, 2000 11:10 AM
Subject: Re: [Zope-PTK] feature request: news categories


> There is no reason to think that putting content in a central place will
> magically solve all problems regarding change.

This is certainly true.

> I'm still confused as to what is the problem here. What does the PTK
> not do that it should? It lets you put the same kind of content in
> central folders, with the same policies, as in member folders. Should
> it do something different when content goes in a central folder?

I don't think that this thread is saying that the PTK is missing anything.
The PTK provides useful facilities, regardless of whether one chooses to
store things centrally or in individual member folders. Your point is valid
that you can set permissions such that it does not matter where things
reside. And, the flexibility remains so that if it makes more sense to store
objects in some central location, that is an option as well!

In fact, since KM|Net News uses the Catalog as it is, I could certainly make
it support both modes of operation: central storage and member folder
storage...

In my opinion, Keep On Truckin', Mike. I think you guys at DC are doing the
right things, and we're going to see a variety of cool PTK add-ons not long
after PTK is released. Not because the PTK is lacking in anything, but
because it's a good framework and people have found new ways to implement
their applications.

Kevin

At 11:10 Uhr -0500 16.02.2000, Paul Everitt wrote:
>Jochen Haeberle wrote:
> > I think this depends... for content like that on Zope.org, that's
> > perfect. But if you think of some sort of news system, than providing
> > an article is more of "submitting" it to the editor of the paper. I
> > think this is important that the user does not have every control of
> > the article as publishing rights get handed over to the paper... and
> > if the content "moves" out of the users folder when it is sent to
> > review, that's a sign of that legal event.
>
>Who said that reviewing policies were tied to location? Who said the
>user would suddenly get every control of the article?

Oh, no one, but you were stressing the advantages of the me-centered approach.

> > >I don't buy the argument that putting stuff close to people breaks
> > >URLs. Take a look on the web at all the ~username URLs you see out
> > >there. Moreover, deleting a member doesn't delete their content, just
> > >like deleting someone on a Linux system doesn't delete all their files.
> >
> > I guess it would be possible to find means to secure this... ID's
> > need not be editable after all...
> >
> > On the other hand, when using search engines or link lists, you know
> > how much content on the Internet changes. The people on this list
> > might be aware of those problems, but most users we will deal with in
> > the Portals defenitely are not!
>
>You seem to argue, "Don't let users author anything, because they might
>change it, and thus break search engines." You can certainly have a
>portal where members aren't allowed to author anything.

No. I want users to participate and author and submit but I think
there needs to be some logic looking after them when their content is
reviewed and publicly available. We talked about what is going to
happen when user change reviewed content, that's about the same. When
the content is linked to we should make sure things can't get deleted
and modified all the user wishes for. I think this is desirable in
the sense the web should work, although the present situation all
around differs from this ideal... this is Zope isn't it? I think we
are up for something better....
I just think the portal owner should be in charge what is publicly
available on his site. This is a legal requirement over here in
Germany. What if an evil minded user submits a nice, firendly article
but totaly changes the content once it was reviewed and published to
Nazi-propaganda for example??

This does not go for all content, but for sure for articles or news
items, even discussion-entries. Things are different for HowTos, Tips
etc. where the user sort of is maintainer. Still every change to a
published content should be reviewed before going public.


>There is no reason to think that putting content in a central place will
>magically solve all problems regarding change.
>
>At the end of the day, though, please remember: it's just like HTML
>files on websites. You can put them in your home directory, or if the
>local policies require that you put them in a central area, you can do
>that as well.
>
>I'm still confused as to what is the problem here. What does the PTK
>not do that it should? It lets you put the same kind of content in
>central folders, with the same policies, as in member folders. Should
>it do something different when content goes in a central folder?

Perhaps. I think it should be some logic to what is stored in the
users area and what not. What's in the user's folder, s/he is
"maintainer" of. Other content is edited in the users folder but
moves to a central place when submitted for review. That's content
that should normaly not be changed later, at least not easily, like
news, stories, articles )in the sense of a newspaper)
Well, I was just responding to your arguments in favour of the
me-centric approach, as I felt this is because you are looking at
portals of the Zope.org kind. This is not the type of portal I am
most interested in. I just wanted to stress that there are other
interesting uses of PTK!


Regards

Jochen

On Wed, 16 Feb 2000, Jochen Haeberle wrote:

> This does not go for all content, but for sure for articles or news
> items, even discussion-entries. Things are different for HowTos, Tips
> etc. where the user sort of is maintainer. Still every change to a
> published content should be reviewed before going public.

I have much the same concerns. There is a solution to this problem
already in the PTK. When a user performs a change operation, a hook on
the Portal is called. This gives you an opportunity to 'unpublish' an
item, or set it to 'pending review', or just let it go through, depending
on your policy. This hook is... umm... notify_content. Actually, it
occurs to me that I may not be calling this hook yet. I think we might
have just realized it was a good idea and put it in, but were in too much
of a hurry to hook it up. I'll make sure it is called in the appropreate
places.

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434

Jochen Haeberle wrote:
> Perhaps. I think it should be some logic to what is stored in the
> users area and what not. What's in the user's folder, s/he is
> "maintainer" of. Other content is edited in the users folder but
> moves to a central place when submitted for review. That's content
> that should normaly not be changed later, at least not easily, like
> news, stories, articles )in the sense of a newspaper)

Why not just tell the user to author the content there, or customize the
creation to automatically have it placed there?

As for the Nazi propaganda, there are permissions and there is a review
policy. If you think these two don't provide enough control, suggest
something else, but I certainly think these cover it.

> Well, I was just responding to your arguments in favour of the
> me-centric approach, as I felt this is because you are looking at
> portals of the Zope.org kind. This is not the type of portal I am
> most interested in. I just wanted to stress that there are other
> interesting uses of PTK!

It's true that Zope and the PTK are about safely delegating control.
But still, there is NOTHING that I can see that prevents a different,
centralized model. If the policy is, "Nobody is trusted", then
implement that policy. Just require that everything be reviewed and
disallow authoring in member folders.

I'm going to stop on this thread. As far as I can tell, everything you
want is anticipated by the PTK. If not, then we'll need to add it.

--Paul

>-----Original Message-----
>From: paul@zope.org [mailto:paul@zope.org]On Behalf Of Paul Everitt
>Sent: Wednesday, February 16, 2000 6:07 AM
>To: Chip Vanek
>Cc: zope-ptk@zope.org
>Subject: Re: [Zope-PTK] feature request: news categories
>
>
>Chip Vanek wrote:
>> I too am very interested in categories. When you talk about
>> subclassing the News object below and using folder do you
>> mean that the object would be stored in this folder?
>
>Long thread...sorry for the delay in replying.

What!, you don't have a Ztopic categorizing all threads as they
come in and presenting possible action for you ;)

>
>> The present PTK keeps all objects in the authors members folder or
>> children. I do not know if this is by design or just present
>> convenience. It does seem to simplify security and the review/
>> publishing mechaism seems to allow for managed publishing.
>
>Just like Zope.org, content can be anywhere. But giving people a
>"me-centric" view of their content is powerful.
>
I am getting more comfortable with the Zope.org way and think I am
being very supportive of the concept in my too long comments.

>I don't buy the argument that putting stuff close to people breaks
>URLs. Take a look on the web at all the ~username URLs you see out
>there. Moreover, deleting a member doesn't delete their content, just
>like deleting someone on a Linux system doesn't delete all their files.
>
I think that putting stuff close to the author and giving them good
content management tools is the best way to ensure quality content.

>Regarding the idea of folders based on categories, this is precisely
>what Topics are to do, with the advantage that the same item can appear
>in *many* places. A Topic is like a folder where most of the
>items come
>from a catalog lookup.

In my message list search yesterday, I found for the first time you
Ztopic comments. Ztopics looks exactly like what I had in mind. I have
not looked with any detail at Ztopics but, will try in integrate or
follow others work as soon as I get this first implementation done.

>
>Note, thought, that the items aren't _really_ in the folder. When you
>click to visit the item, it goes to the real URL. Perhaps that's not
>what you want.
>
The "click to visit the REAL URL" is exactly the functionality I would
like to see. Let the content stay with the owner yet have your own
personal Topic descriptor of what is in the content.

>> I am new to Zope and cannot yet figure out how to create an
>> object in another folder and set the correct permissions. I was
>> able to subclass the portal document object and add category
>> fields (properties). I am now struggling with trying to enter
>> this category property in the Catalog as a Keyword Field.
>
>Hmm, are you saying you can't create a Portal Folder, then create stuff
>in there?
>
Yes, I am struggling with adding Portal Folders. I like the idea of the
PTK "management screen eliminator" wrapper around addPortalFolder, but
keep getting security access violations. I think that I am setting the
"Add Folder" permission on the target folder and have tried proxy roles
but, something I am doing is just wrong.

>> Then to simulated category lookup I would like to create
>> a search query that returns just items of a certain category.
>> It looks like the PTK wrapper around Zcatalog will ensure that
>> only authenticated users can see non-public items. The big problem
>> I have now is finding the syntax for getCatalog().searchResults(....)
>> to give me just the items with the keyWorks I want.
>
>Yep, that's an issue.
>
>> To automate the management and generation of the KeyWords, I was
>> going to use a "tree" of folders that have titles that match the
>> KeyWords. Then, using acquisition one query method would parse
>> the branches of the tree up to root and have the KeyWords. The
>> "tree" of keywords would be a hierarchical oncology of topics
>> hosted by this site. Adding a new topic is just adding a new
>> folder to the tree. Then a compact version of this tree needs to
>> be available to the user in the add and edit forms of the object
>> to ensure that correct KeyWords are used.
>>
>> This is likely a ugly hack of an approach but, it fits in my feeble
>> mind and I can see the steps to complete it if I start getting
>> some help from the list ;).
>
>Hopefully Topics will help this. I'll check on the ETA for Topics.
>
>--Paul
>
Yes, ZTopics sounds like the solution. I will revisit the solution
when ZTopics becomes closer to reality.

Thanks for your comments.

Chip

>_______________________________________________
>Zope-PTK maillist - Zope-PTK@zope.org
>http://lists.zope.org/mailman/listinfo/zope-ptk
>
>