Mailing List Archive

[Zope-PTK] Search engine woes solved, sorta
So I've been pulling out hair, making sacrifices to the gods, and
generally making an annoyance out of myself as I struggled to figure
out why my PTK search engine wasn't working, and I've finally figured
it out, I think? But this leaves me with more questions than answers.

It seems that Document, NewsItem, Link, etc. are the only items which
show up by default on my PTK site. This is helpful in one sense, since
I'm trying to allow for advertising, but I'd still like to support
moderation to ensure that the advertising is appropriate to my
site. However, my circumstances are a bit unusual, and I'd like to see
if there is some other way to solve my problem.

As previously stated, this site is for a student organization, a sort
of "student government." Instead of concerning ourselves with the
entire campus however, we're only concerned with one residence
hall. The officers in this organization change yearly, and many
residents arrive and leave regularly. So, our community is fairly
dynamic.

I'm using the PTK to empower residents and officers to contribute more
freely in areas which they haven't been able to in the past. Residents
can apply for accounts and write articles for our newsletter,
advertise for any events which they are coordinating, etc. The PTK
works well for this, but it seems to be designed for a more static
community.

I like the fact that the PTK Z Catalog only indexes specific items,
since that reduces the likelihood for abuse. However, is it somehow
possible to index content in specific "trusted" folders, without
requiring publication/approval first? As an example, I wrote a
document which explains how to use the Event wizard and the Ad Banner
Wizard which I'm writing to advertise. I originally wrote it as a DTML
method and placed it within a help folder. The URL to the document was
originally mysite.org/help/advertising. Transferring this text to a
Document and placing it in my personal folder changes the URL to the
much more forgetable mysite.org/Members/myusername/advertising. Once I
used a Document for storing the text though, the search engine finds
it nicely. Similarly, we will be publishing a newsletter using Zope as
a means for colaboration and, thanks to ZPDFDocument, a quick way to
spit out a printer-friendly version of our work. I would very much
like to store issues as mysite.org/newsletter/apr00/ instead of
storing each article in several documents in a user folder. This also
allows us to delete the user's account after they are gone, without
fearing that they may have written articles which will be lost.

So, is there an easy way to automatically index certain folders on the
site without a) indexing everything and b) sacrificing the
publishing/moderation facilities which the PTK currently offers?
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
On Mon, 6 Mar 2000, Nolan Darilek wrote:

> I like the fact that the PTK Z Catalog only indexes specific items,
> since that reduces the likelihood for abuse. However, is it somehow
> possible to index content in specific "trusted" folders, without
> requiring publication/approval first?

There's _always_ a way. ;-)

You seem to want content to be automatically published on
submission. If it is suitable that submittion and publication remain
seperate steps, but without the requirement of reviewer intervention in
specific cases, it is easy to implement. You have to extend your portal's
'before_review' hook. In this hook, you can check to see if the content
exists in a 'review free' zone, and if so, promote the review request to a
publication.

If it's not suitable that content starts out as 'private', it's a
simple matter to set an object's 'review_state' property in it's
constructor. Set it to 'published' before the object is initially
cataloged, and you're in business.

I can provide more detailed instruction if you need it.

This all asumes that you are somehow subclassing PortalContent, which
is required.

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
----- Original Message -----
From: "Mike Pelletier" <mike@digicool.com>
To: "Nolan Darilek" <nolan_d@bigfoot.com>
Cc: <zope-ptk@zope.org>
Sent: Tuesday, March 07, 2000 11:52 AM
Subject: Re: [Zope-PTK] Search engine woes solved, sorta


> On Mon, 6 Mar 2000, Nolan Darilek wrote:
>
> > I like the fact that the PTK Z Catalog only indexes specific items,
> > since that reduces the likelihood for abuse. However, is it somehow
> > possible to index content in specific "trusted" folders, without
> > requiring publication/approval first?
>
> There's _always_ a way. ;-)
>
> You seem to want content to be automatically published on
> submission. If it is suitable that submittion and publication remain
> seperate steps, but without the requirement of reviewer intervention in
> specific cases, it is easy to implement. You have to extend your portal's
> 'before_review' hook. In this hook, you can check to see if the content
> exists in a 'review free' zone, and if so, promote the review request to a
> publication.

Actually, isn't there a "Contributor" role that is supposed to be able to
publish without review? You can always set things up so that those certain
submissions use a proxy role of Contributor to circumvent the review
process...

Kevin
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
On Tue, 7 Mar 2000, Kevin Dangoor wrote:

> Actually, isn't there a "Contributor" role that is supposed to be able to
> publish without review? You can always set things up so that those certain
> submissions use a proxy role of Contributor to circumvent the review
> process...

Good point. This role's privilages are implemented in the
before_review hook, so you can see how it could be done for other
situations.

> Kevin

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
>>>>> "Mike" == Mike Pelletier <mike@digicool.com> writes:

Mike> There's _always_ a way. ;-)

Good! :)

Mike> You seem to want content to be automatically published
Mike> on submission.

Not exactly. :)

I have no problem with the current publication mechanism. It suits my
needs quite nicely, in fact.

I'm designing a portal site in a community whose members change very
often, maybe twice a year. Right now I have /Members/nolan where I'll
write all of my personal articles for our newsletter, meeting
information, etc. But, when I leave the organization, we may wish to
delete /Members/nolan to free up space/resources, etc. So, I'm not
concerned with the publication mechanism; instead, I'm concerned about
how a community member's content can a) remain after he leaves and b)
be indexed in the Z catalog.

I've thought of two basic approaches. One approach is to use
PortalContent classes such as Document, NewsItem, my new Event class,
etc. for all searchable site content. Thus, I don't need to muck with
the Z catalog settings at all, and can still use the
publishing/approval mechanisms.

As an example of this, I'm writing basic howto's about certain site
activities to make using the site easy for anyone, but I'm not the
best writer (as you can probably tell by this email :). I'm concerned
that my document on how to advertise may be unclear, that I may not be
mentioning something that I should, etc. So, someone copies the text
of my document into their folder, edits it, and creates a new version
which I link to. When they leave the organization though, I'll need to
remember "Hey, the advertising document is in his user folder, so I
need to move it out." (Yes it'd make sense to just copy the document
into my folder, but I'm trying to anticipate what mistakes future site
maintainers may make.)

A perfectly logical solution to this is to create Documents in other
folders. For example, I have a regular /help folder. If I could select
'Document' just as easily as I select 'DTML Document/Method' and add
the document to this folder, I'd never have to worry about removing
someone's folder and breaking site-wide links. Similarly, if someone
writes an article for our newsletter, I don't want to erase it when I
remove their account, thus breaking links in the newsletter. So, I'm
trying to determine if it is somehow possible to a) create PortalContent
in the same manner that DTML Documents/Methods are created or b) add
specific, trusted, non-PortalContent objects into the Z catalog? For
some reason I can't get any of my non-PortalContent objects to index.

Anyhow, sorry if I've been a bit too verbose; hopefully you're so sick
of hearing about my problem that you understand it fully, and have
10-20 solutions for me. :) Thanks a bunch.
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
Sorry, I didn't read closely enough. Let's take another crack at it.

> I'm designing a portal site in a community whose members change very
> often, maybe twice a year. Right now I have /Members/nolan where I'll
> write all of my personal articles for our newsletter, meeting
> information, etc. But, when I leave the organization, we may wish to
> delete /Members/nolan to free up space/resources, etc. So, I'm not
> concerned with the publication mechanism; instead, I'm concerned about
> how a community member's content can a) remain after he leaves and b)
> be indexed in the Z catalog.

I think that the best solution would be to set up a containment tree
outside /Members, giving the appropreate people the appropreate
permissions to add items. Items could either be added directly, or added
and composed in the Member's home area and them 'committed' to the
perminant location. The second method gives you an opportunity to reduce
the contributor's rights to the object to prevent dead links, etc.

> So, I'm trying to determine if it is somehow possible to a) create
> PortalContent in the same manner that DTML Documents/Methods are
> created

I'm not 100% sure what you mean by this, but I believe the answer is
yes, you sould be able to instantiate PortalContent-derived objects in the
same manner as any other object.

> or b) add specific, trusted, non-PortalContent objects into the Z
> catalog? For some reason I can't get any of my non-PortalContent
> objects to index.

While you might get lucky with this, this is probably a Bad Thing to
do. Many reports are going to assume any object it pulls out of the
catalog will provide certain basic services that non-PC objects won't.

It's not difficult to make an arbitrary Zope object portal-manageable.
Theoretically, if you're using ZClasses, you can just mash the two
together, and it'll "just work". (Let me know if you try this and find it
actually works!!)

I've been sitting on an example which mixes Zope's File object and
PortalContent. It's a Python class. I've just committed it. I haven't
finished tweaking it, so I haven't made it available yet. It can be made
available by importing it in the __init__ module, so it has a chance to
register itself. It does work, and can serve as a decent guide. Later
today, I'll have commentified it better.

If some subtle (I'm being kind to myself) detail has yet escaped my
understanding, let me know and I'll try again. ;-)

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
>>>>> "Mike" == Mike Pelletier <mike@digicool.com> writes:

Mike> I think that the best solution would be to set up a
Mike> containment tree outside /Members, giving the appropreate
Mike> people the appropreate permissions to add items. Items
Mike> could either be added directly, or added and composed in the
Mike> Member's home area and them 'committed' to the perminant
Mike> location. The second method gives you an opportunity to
Mike> reduce the contributor's rights to the object to prevent
Mike> dead links, etc.

Ah, that sounds doable.

Mike> I'm not 100% sure what you mean by this, but I believe
Mike> the answer is yes, you sould be able to instantiate
Mike> PortalContent-derived objects in the same manner as any
Mike> other object.

Hmm, I don't see how.

I'm using the management interface, and don't see any of the
PortalContent objects (Document, Link, NewsItem, etc.) in the list. I
see Portal, Portal Folder and Wizard, though. I suppose I could just
create them in my members area and move them out. How exactly does the
cut-n-paste mechanism work? Does it use cookies, or something else?
I'm using emacs/w3, which basically places each page in an emacs
buffer. So once I cut the item, I switch to the buffer containing the
destination page, reload it, and try to click on 'Paste'. This doesn't
work for me, though, and it may be due to bugs with w3's cookie
support. Or, should I instead follow links to the new pages? I guess
what I'm trying to ask is, is the cut-n-paste mechanism driven by
traversal, cookies, or something else entirely? Also, what is the
difference between Portal Folder and Folder? I've been creating
regular folders; should I convert these to Portal Folders?

What happens to an object when its owner's
user is erased but the object still remains? Is its owner changed to
the superuser or manager?

Mike> I've been sitting on an example which mixes Zope's File
Mike> object and PortalContent. It's a Python class. I've just
Mike> committed it. I haven't finished tweaking it, so I haven't
Mike> made it available yet. It can be made available by
Mike> importing it in the __init__ module, so it has a chance to
Mike> register itself. It does work, and can serve as a decent
Mike> guide. Later today, I'll have commentified it better.

Cool -- looking forward to seeing it! My next project is a Newsletter
Z Class; something which basically squeezes several documents and
images together into one single Z Class.

As another completely random question, I have several classes which
weren't distributed with Python source, but which I'd like to make
more portal-aware. I'm using ZRTChat, for example. I'd like to hack it
so that it only allows you to enter the room under your Zope username,
and not any arbitrary name. I'm also using an ad banner system (I
can't remember which one ATM) and I'd like to make it portal-aware so
that I can use the Ad wizard which I've partially created so that
folks can upload ad banners. I could derive a class if I had the
Python source, but what if the products are only distributed as
.zexp's? Is it possible to modify these products so that they work as
PortalContent? I know the LoginManager is meant to remedy this, but
since I'm only attempting to use PTK user names in a chat room,
LoginManager may be a bit much.

Mike> If some subtle (I'm being kind to myself) detail has yet
Mike> escaped my understanding, let me know and I'll try again.
Mike> ;-)

Nah, this has been helpful. I guess I'm still
trying to come to terms with the Zope/PTK-specific way to solve
problems. For example, I'm used to designing static websites, so
handling more community-driven sites is new to me. Thanks for the
help!
Re: [Zope-PTK] Search engine woes solved, sorta [ In reply to ]
On Wed, 8 Mar 2000, Nolan Darilek wrote:

> I'm using the management interface, and don't see any of the
> PortalContent objects (Document, Link, NewsItem, etc.) in the list.

Oh dear, you're correct, they're not there. I must have broken this
recently. I'll see what I can do about it shortly.

> How exactly does the cut-n-paste mechanism work? Does it use cookies,
> or something else?

It uses cookies.

> I'm using emacs/w3, which basically places each page in an emacs
> buffer. So once I cut the item, I switch to the buffer containing the
> destination page, reload it, and try to click on 'Paste'. This doesn't
> work for me, though, and it may be due to bugs with w3's cookie
> support.

Yeah, it sounds as though it's not sharing cookies between browsers.

> Also, what is the difference between Portal Folder and Folder? I've
> been creating regular folders; should I convert these to Portal
> Folders?

The Portal Folder implements a bunch of methods which support the
Content Manager's interface. (My Stuff) I would have preferred to put
these methods on the portal and allow the folder to acquire them, but that
doesn't work so well. I think I might know why now, so they may go away
sometime soon.

You should use Portal Folders anyplace you intend to add Portal
Content. Sorry.

> What happens to an object when its owner's
> user is erased but the object still remains? Is its owner changed to
> the superuser or manager?

Presently, I think the object would become 'unowned', but it may stay
owned by the nonexistant userid. I'm not certain. The behaviour is
defined by the local roles machinery. (Ownership is just a local role.)
I don't know what happens to a user's local roles if they are deleted...

> Cool -- looking forward to seeing it! My next project is a Newsletter
> Z Class; something which basically squeezes several documents and
> images together into one single Z Class.

I was unclear. The code is in the CVS, but it's not imported anywhere
at the moment. So, it's available to examine, but it's not available to
use unless you modify your __init__.py module to import it.

> As another completely random question, I have several classes which
> weren't distributed with Python source, but which I'd like to make
> more portal-aware. I'm using ZRTChat, for example. I'd like to hack it
> so that it only allows you to enter the room under your Zope username,
> and not any arbitrary name. I'm also using an ad banner system (I
> can't remember which one ATM) and I'd like to make it portal-aware so
> that I can use the Ad wizard which I've partially created so that
> folks can upload ad banners. I could derive a class if I had the
> Python source, but what if the products are only distributed as
> .zexp's? Is it possible to modify these products so that they work as
> PortalContent?

If you're feeling superstudly, you can modify a ZClass's base classes
in-place. So, you could insert PortalContent. If your database slaps you
around, insults your fashion sense and self-corrupts, you're on your own.

The other posibility is to simply subclass the ZClass, mixing in
PortalContent. This is untried, but aughta work. To be honest, though, I
haven't tested ZClass-based portal content objects in a while. Let me
know how it works out if you try it.

Mike.

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