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
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
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 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list