Jim Fulton wrote:
> 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.
that's possible, when you can more you can less (or differently)
> - 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.
yes, this is a possible extension, it is also possible to create a new
types of objects that fits your needs that are neither slots nor
portlets but that are contained inside cells.
why not create a portlet that does what you want? the main formal
difference between slots and portlets is that slots are inner nodes
(physically or virtually contain other objects) and that portlets are
node leaves (must render some data).
here is the actual base classes:
this is important for the theme editor.
if the new type of object that you are thinking of work like an inner
node, then it's a slot otherwise it's a portlet.
basically if the "slot" that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.
> - 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.
yes, any term, "boxes" are not OK, since they refer to the portlet's
display (view) with the frame and the decorations but any term that is
understood by users / developers is ok.
Zope3-dev mailing list