Ticket #1126 (assigned defect)

Opened 3 years ago

Last modified 3 years ago

[boxless] Documents are rendered twice

Reported by: gracinet Assigned to: jmorliaguet (accepted)
Priority: P1 Milestone: CPS 3.5.0
Component: CPSDefault Version: TRUNK
Severity: normal Keywords:
Cc:

Description

To reproduce, on a fresh portal, create a document at root of workspaces. It will be displayed twice, once above the psm, once below.

This is probably because the Document Portlet's guard is too weak (from the installer)

               {'type': 'Document Portlet',
                'slot': 'content_well',
                'visibility_range': [1, 0],
                'order': 10,
                'Title': 'Document Portlet',
                'guard': {
                    'guard_expr': "python: published != 'folder_contents'",
                    },
               },

In our case, 'published' is equal to 'cpsdocument_view'

I put TRUNK but this is actually about HEAD of the jmo_boxless branch

Change History

11/11/05 18:52:14 changed by jmorliaguet

  • owner changed from trac to jmorliaguet.
  • status changed from new to assigned.

OK, now I see.

What happens if you write instead:

guard_expr': "python: published == 'cpsdocument_view'",

there are by the way lots of action methods that give the same results now that the boxes are removed.

Since CMF supports aliases so why not remove the (empty) 'folder_view.pt' and the (almost empty) 'folder_contents.pt' templates and use the CPSDocument view instead for the view / folder contents actions?

  • folder_view => cpsdocument_view
  • folder_contents => cpsdocument_view

I guess that this would solve some of the problems related to css resources that are missing when rendering documents with 'folder_view' or with 'folder_contents'

11/11/05 19:44:03 changed by gracinet

I get it again twice with published == 'cpsdocument_view' You probably meant published != 'cpsdocument_view' But this would mean that the document gets displayed on all pages but 'view'. I'm not sure about your plans, though: what's supposed to be taken care of by page templates, what's delegated to portlets ?

The way things are right now, this seems to mimic the trunk behaviour, but this isn't maybe the way you want things to work: published == 'folder_view' Since 'published' is the id of the called page template, renaming what the actions point to would break this. So folder_view/folder_contents are used, but only for their name. This is a bit of a hack.

A side note: this is also related to #886, since I'd like to implement a section front page by means of a portlet document pointing to a document in the folder, with no listing of contents. Again here, requiring 'folder_view' is a solution that would work for me, to avoid the portlet to be rendered in sub-objects while providing access to the list to admins by means of folder_contents.

11/11/05 22:40:17 changed by jmorliaguet

Nothing is to be taken care of by page templates unless there is a CMF form (login_form, ...)

folder_contents is taken care of by a navigation portlet and folder_view is taken care of by a document portlet.

The idea is to never show these two portlets simultaneously. So I guess the guard for the folder_contents portlet is

guard_expr': "python: published == 'folder_contents'"

and the one for the 'folder_view' portlet is

guard_expr': "python: published == 'folder_view'"

then folder_view and folder_contents can be aliases for cpsdocument_view, and we can use something else than 'published', I guess that the current action is available in the request somewhere already.

what I would like to get rid of is the folder_view.pt and folder_contents.pt templates that do strictly nothing.

then you can used the guard in the way you want to control portlet visibility, you have access to the request, to the context, and all sorts of data ... that shouldn't be too difficult to find the right visibility expression from that based on what you want to achieve.

11/11/05 22:55:32 changed by fguillaume

I agree that the decision should be made based on CMF action aliases. Unfortunately we aren't really using aliases today, but I think once everything is cleanly configured using CMFSetup it will be quite easy to change.