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:

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).

Well, after our various discussions, I think I understand what this
is about.

I have the following suggestions:

- I think the perspective idea has a lot of merit, however, I'd
  like it to be optional.  In particular, I'd like to be able to use
  CPS Skins without having to use perspectives.

- You said that cells can be filled with portlets or with slots.
  Why not make a slot another kind of portlet?  Then people could
  introduce new slot types and innovations without affecting the
  rest of CPS Skins.

- Use of the term "portlet" here leads to confusion with JSR 168
  portlets, which are different.   I would prefer to see a different
  term used for what CPS calls portlets. Absent that, we'll need to
  find some modifiers to disambiguate.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to