Page Comparison

...

There are a couple ways to implement providing such a user experience. One way, the currently implemented way, is to use the CError framework which will replace missing channels with a generic error message indicating that the channel is no longer availalble.

An alternative, more powerful way is that of changing the channel definition to describe a channel that provides the desired user experience. From the perspective of the uPortal framework, there is no error. This could be implemented with a CWebProxy pointed at static HTML, say. This approach requires more work for each channel deletion, but offers benefits in supporting providing a very specific, supportive UI helping the user through channel EOL.

Dropping the error message

So dropping the framework behavior of displaying an error message when a deleted channel is in the user's layout doesn't drop the ability for deployers to provide that user experience when desired. But it would add the ability to not tease users about channels they can't have anymoreSome deployers may want to simply make a channel disappear. This might be because the static "Sorry, your channel's gone" message has been going on long enough, or it may be because the desired user experience is one of a "here today, gone tomorrow" approach – the sooner the channel disappears completely the sooner the users can forget about it. Maybe the channel functionality has been subsumed into another channel that has been injected nearby on the layout.

There are two ways to accomplish this. First, when an administrator deletes a channel, uPortal should find and remove references to that channel to maintain referential integrity of the domain model. Layouts shouldn't reference channels that don't exist anymore.

Second, when a layout manager tries to render a channel that doesn't exist, it should fail quietly, or at least be configurable to do so. This is required even if cleanup at channel delete time is implemented, since some layout sources may not support the callback telling them that a channel is no longer available. So, bad channel references shouldn't happen, but when they do happen the layout rendering pipeline should quietly drop the missing channels. Quietly doesn't necessarily mean silently. Perhaps a web browser's handling of bad JavaScript is a decent metaphor. When rendering a layout with recoverable problems such as references to bad channels, uPortal might insert into the header something like

There were errors displaying this page.

Such an advisory, or the ability to opt into warning messages for missing channels, wouldn't be appropriate for every user, but might be a worthwhile feature to help administrators debug layouts via the UI. And it goes without saying that handling of recoverable problems like missing channels would be logged.

Administratively

Ideally, channel deletion would find and drop all references to the channel in user layouts, to maintain referential integrity in the uPortal data model (no layouts reference non-existing channels). Even more ideally, it would have an ability for a deployer to replace the references with references to a different channel, thereby easing failing over a doomed channel to its static message replacementa replacement message as described above. These enhancements would reduce the incidence of layouts referencing deleted channels.

...

Implementation

Dropping referencs to channels at the time of channel deletion could be implemented by a callback to the LayoutManagers to advise them that a channel has disappeared. Supporting Layout manager implementations would update their layout definitions to no longer use the deleted channel, replacing it with another channel if so advised.