On Aug 24, 2005, at 2:24 PM, Jean-Marc Orliaguet wrote:


Somehow related to the discussion on optimizing catalog queries, I have been thinking about how to best implement local portlets in cpsskins in terms of scalability, performance and functionality. The implementation
is heavily dependent on being able to performance effective catalog
queries (it is OK to wait 2 seconds in an ECMS to search 1 million
documents, but it is not OK to have to wait 2 seconds to render a page
containing portlets).

Here is the proposal:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/ 2005_08_24_local-portlets

It is built on the notion of "Perspective" (see the link) and on the
idea of querying the catalog using triadic relations instead of joining
sets of query results based on dyadic predicates (such as with RDF).

I need to read more to have a more complete reply (though I'm hoping Benji will do it for me, since he knows more about CPSSkins than I), but here are a few responses, based on reading it and talking it over with Benji.

Your overall model is interesting to me because it goes a good way to unifying the various portlet use cases. I know of six categories: page designer wants to fill slots for a site; page designer wants to fill slots for a section of a site; page designer wants to fill slots for a page on a site; user wants to fill slots for a site; user wants to fill slots for a section of a site; and user wants to fill slots for a page on a site. The section and page use cases might be collapsed technically, but have a different feel to a user, IMO, and so should be separated. Combining these into a unified model is impressive and cool.

I worry that the description does not get into the possible UI expectation differences between a page designer and a user, and between working on a site or section versus a single page. These seem like tricky UI bits to get right to me. I'd be interested in seeing a discussion of your thoughts of the UI from this perspective, especially in regards to showing a user, within an editing screen, which portlets are being edited from a page perspective, from a per- user perspective, from a section perspective, and so on. It seems like it could cause information overload.

The 'perspective' idea is a good concept for the discussion (and I used the word above), but you claim that it is a single element in a triadic relationship, then list several perspectives, each of which could influence the lookup. This means to me that it is not triadic but 'n-ary'. Moreover, it seems a lot more like a graph walk, for which we don't need new code in CPSSkins, than a new n-ary data index. RDFLib or any similar graph implementation with typed relationships would get the efficiency you want, as far as I can tell, with a lot less new code to maintain.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to