Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

About this page

This page is for describing desired uPortal behavior when channels are deleted. It is a child of the Layout UI page because the primary discussion is of what the end user experience should be (error messages or fail more quietly), tho the page also discusses implementation.

Deleting channels

Current behavior

It appears that if a channel has been deleted but it is still in the user's layout, an error message is displayed.

Desired behavior

If we decide to decommission a channel at some point in the future, we would like it if it was removed from users' layouts or at least not displayed in the form of an error message.

Better error messages

In many cases a portal administrator would want to incrementally decomission a channel. If in that process a deployer desires that the channel be replaced for a time with a static message.

SplatUpdates no longer available

We're sorry, but the SplatUpdates channel is no longer available.

Feel free to remove this channel from your layout by using the X control in the upper right corner of this channel. On (SOME_DATE) this channel will be automatically removed from all layouts.

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

Some 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

(warning) 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 a replacement message as described above.

Deleting channel SplatUpdates

Are you sure you want to delete SplatUpdates?

(warning) There are 47 end user composed layout fragments and 3 centrally managed layout fragments referencing this channel. How would you like uPortal to handle references to this channel?

(x) drop references to this channel from layouts (including end user composed layouts and centrally managed layouts).
( ) replace references to this channel with references to another channel (you will choose the channel on the next screen)

(Yes, delete the channel) (No, do not delete the channel)

And of course, if there are no references to the channel, uPortal should reassure the administrator of this:

Deleting channel *SplatUpdates*

Are you sure you want to delete SplatUpdates?

No end user managed layouts and no centrally managed layouts reference this channel.

(Yes, delete the channel) (No, do not delete the channel)

  • No labels