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.
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.