All project content is available for reading, but you need to be a member of the project for Subversion checkout of source code, or to create/modify any information.
Login if you are a member. Apply here to request membership (open to all).

Ticket #41 (new enhancement)

Opened 13 years ago

Last modified 13 years ago

Version handling

Reported by: tomas.lundgren@… Owned by: mari@…
Priority: minor Component: EPiWebPart
Keywords: Webpart framework Cc: steve@…


A suggestion to improve the webpart framework is to add version handling to all changes made on the webpart page.

Change History

comment:1 Changed 13 years ago by steve@…

  • Cc steve@… added

This is a good suggestion, one that we have discussed on numerous occasions.

From a technical viewpoint, doing this should not be that hard, but the user interaction might be more tricky. How do we show the different versions available, rely on the user to understand and use the page versioning correctly? Maybe. The current way of doing page versioning in EPiServer is poor, and I've seen to many users "lose" their changes because they do not understand that they're looking at the published version of the page, not the one they edited yesterday.

Relying on the page versioning alone will only expose this weakness more, and make users lose their work. We need something more. Perhaps a note directly in the user interface that there are unpublished versions newer than the one they are trying to edit - with a quick way to change to the latest one.

Saving the data could be done by changing the PageDataPersonalizationProvider.cs to store the blob of web part data as a base64 encoded string in a property on the page. It means that we need a new custom property data type (longstring) to hold the values. With the new read-only pagedata cache in CMS 5, decoding and de-serializing the data would only needed to be done once (as long as the page is in the cache.)

The custom property data type could also allow for some administrative operations on the blob, directly from edit mode, like deleting it (in case it gets corrupt), or perhaps initialize it from some saved state (like having predefined "web part layout templates" for ease of use.)

Being stored on the page also helps when copying pages around, as we'd copy the web parts too (which is not the case today.)

If time permits... feel free to try implementing it though.

Note: See HelpUser/Tickets for help on using tickets.