change publication status behavior for containers

Bug #101205 reported by Martijn Faassen
10
Affects Status Importance Assigned to Milestone
Silva
Fix Released
Low
Unassigned

Bug Description

For reasons of performance and predictability, it would be good to change the
way folders determine they're public. Right now, a folder determines it's public
if anything inside is public. This means that if nothing is public inside, Silva
recurses through the entire (potentially vast) tree asking any object whether it
is public. This may result in workflow status changes, triggering publication
and catalog indexing even.

Obviously this is not ideal for performance. It also leads to odd behavior if
non-versioned content (such as auto-tocs) are found. These are always published,
meaning that the container they are in (and the container those containers are
in, etc) are automatically published.

There are obviously issues with such a behavioral change. Let's discuss them here.

Revision history for this message
Samuel Schluep (schluep) wrote :

A problem, which might be related to this issue is the updating of metadata
rendered by ghosts. If the metadata of some content changes, ghosts pointing to
the content currently don't get updated. As an effect, the short title of ghosts
are not updated in the sidebar of the SMI or in the public view.

A possible solution I can think of is inspired by the event model used in Java.
A component can fire events, e.g. a status change event. When an event is fired,
is is received by one or more "listeners", which act on that event. Any
component, which wants to know about a special event of a specific component,
would define an event listener and register the listener with the firing
component with a "addXXXListener()" function. The firing component maintains a
list of listeners, which will be called when the event is fired.

In Java listeners are defined as interfaces, which will be implemented by the
listening component defining the actions the component should perform on the
event. The event types are defined as classes containing the event data.

For example a "StatusChangeEvent"-type could be defined. Components, whose
status may change, will maintain a list of "status change listeners" and define
a "addStatusChangeListener()" and a "removeStatusChangeListener()". Ghost and
folders would implement a "StatusChangeEventListener" and register it in all
content types they point to or contain respectively. A status change of a
component will then pass the "StatusChangeEvent" to all registered listeners,
which will update their data or invalidate the sidebar cache or what so ever.

Revision history for this message
Martijn Faassen (faassen) wrote :

Just as a note: an event system for Silva is indeed very desirable. In the past
I've spent some time with the Zope 3 event system for Zope 2 (in the context of
Five), in the hope to eventually adopt it for Silva. This is a moderately large
job however, so it won't be in scope for 1.2.

Revision history for this message
Andy Altepeter (aaltepet) wrote :

As of silva 1.6 (so marking this issue as fix released)

The published status of containers changed: A folder is published
        when its default document is published, not published when its
        default document isn't published, and if no default document is
        present, it is considered published if any of its contents are
        published. This cuts down on some unnecessary recursion, as well as
        giving editors a nice way to temporarily exclude trees from
        navigation, so that they can be worked on.

Changed in silva:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.