change publication status behavior for containers
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.
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 "StatusChangeEv ent"-type could be defined. Components, whose eListener( )" and a "removeStatusCh angeListener( )". Ghost and entListener" and register it in all
status may change, will maintain a list of "status change listeners" and define
a "addStatusChang
folders would implement a "StatusChangeEv
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.