[Zope-PTK] "score" or "sortOrder" for PortalContent?

[Steve Alexander]

Kevin Dangoor wrote:
> 
> Dan L. Pierson wrote:
> > So, if 'score' is seen as a method with an arbitrary definition I'm
> > probably for it.  If it's seen as a slot holding a single number, I'm
> > unconvinced.
> 
> I definitely see it as a method that should be overridden for specific
> tasks. In my original example of KM|net News which uses a score that is
> based on importance and release date, "score" would certainly be a method
> that computes the value and not a property holding a number.
> 
> My hope is that everyone can do sort=score, or "'sortOn' : 'score'" for
> ZCatalog queries, for most Portal content. There might be some instances
> where you need to do something that is too complex to even incorporate into
> a method like this... but I don't think there would be many.

I'm going to try and draw out an abstraction from what I've read so far
on this thread.

What this says to me is that classes derived from PortalContent should
be comparable. That is to say, a PortalContent instance can be compared
to another PortalContent instance and you'll be able to tell whether the
first instance is greater than, less than, or equal to the second
instance.

Is there a way to do this that uses, or is similar to, Pythons __cmp__
and __rcmp__ methods? If so, perhaps we'd be better using these than
adding on a "score" property.

As Kevin suggests, score() can be a standard method of PortalContent.
However, rather than returning a number, it can return an object that is
compared to other objects using the __cmp__ and __rcmp__ methods. I
can't see getting much more flexible than that :-)  The object can be a
simple type such as a string or number, or it can be a complex "brain"
that compares via an algorithm or something.


I should add a disclaimer here: I've not looked in the code to Catalog
or the <dtml-in> tag to determine that it works the way I imply. I'm
just guessing.

--
Steve Alexander
Software Engineer
Cat-Box limited