Shame on you Mr EPiServer

Added some more thoughts

We actually considered doing mirroring independent of custom modules. There are some nice benefits with that, one that deployment of custom modules would not be needed and another thing is that it would probably be a lot faster since you can then work with the “raw” data format.
The decision after some thinking was however not to implement it that way. The main reason was that several scenarios require that we need to be able to create PageData (which contains the custom properties) instances. Below are some reasons:

• There are a lot of modules out there that relies on DataFactory events such as CreatedPage, SavedPage, DeletedPage etc. So to get these events fired when doing mirroring as well then we need to create up PageData instances and save those through the ordinary DataFactory API.

• To be able to handle properties that implements IReferenceMap it is required that the property is instantiated (see below on more information about IReferenceMap).

• Using DataFactory API is also required to be able to support mirroring to custom PageProviders.

• For maintainability reasons we did want mirroring to use the same API as import/export (which works with PageData instances).

Regarding the event handlers in DataExporter and DataImporter they are not new in CMS6 but has existed in CMS5 as well so in that matter nothing new is introduced with Mirroring2.0 regarding that.

The idea with the event handlers is to expose an opportunity to handle extra logic for a property when it is imported or exported. A typical use case is when the property has some dependent external resource (like a PropertyUrl referencing a file or a PropertyXForm referencing an XForm) then the event handler is responsible for adding the actual resource (for example a file or an XForm) to the export package.

The events are publically static declared so you can register your own handlers for your custom properties.

The identity of a resource (for example a file or a page) might change during import (otherwise you would not be able to import the same package several times). To handle this scenario a property can implement IReferenceMap. The purpose of IReferenceMap is that a property that implements this interface will at import (before the property is saved) be called with a Guid map as parameter so the property can change its reference to the new identity.

Hopefully you now have some more knowledge regarding why it is implemented as it is. But of course there are always things we can do better. For example your idea of that resources automatically could be found and included in package is interesting and something I hope we can do more around. We are thankful for your feedback and will take that in consideration for upcoming versions.

Hi Johan
I can understand that you have made a choice and then sticking to that.

But after I read what you have said here, I’m wondering if the mirroring stuff is like a new episerver instance? Do it insert directly into the database. I guess so since if you had used the API that would have taken care of the page events.

That takes me to my current problem. How to attach myself to the DataExporter. I need to attach myself to the DataExorter instance that is running in the mirroring pool.

I have tried

[ModuleDependency]
[Serializable, PageDefinitionTypePlugIn]
public class PropertyTestPropertyUrl2 : PropertyString, IReferenceMap, IInitializableModule
{
#region IInitializableModule Members
public void Initialize(InitializationEngine context)
{
DataExporter.ExportPropertyEvent += new EventHandler((PropertyUrlTransform.ExportEventHandler));
}

public void Preload(string[] parameters)
{
}

public void Uninitialize(InitializationEngine context)
{
DataExporter.ExportPropertyEvent -= new EventHandler((PropertyUrlTransform.ExportEventHandler));
}
#endregion

But this doesn’t work. Can you provide an example how we can make our own PropertyUrl property that actually work?

When a mirroring job executes it actually creates an EPiServer.Enterprise.Mirroring,MirroringDataExporter (which inherits DataExporter). Since the event is declared as static it will not be inherited so instead MirroringDataExporter exposes it's own ExportPropertyEvent.

This construction is really not something we are proud of but since the event was declared static and we could not break backward compatibility this was how it was done.

So your code should run just fine if you instead hookup to MirroringDataExporter.ExportPropertyEvent (if you want your code to execute both for mirroring and ordinary export you typically hookup to both events).

It works by hooking up with MirroringDataExporter, but I see that the property is a RawPropertyData, so I have to parse they text instead of useing methods on my property. It's also a hassel since It's difficult to check what kind of type the different properties are.

And the strange part, is that I dont see any difference between this method and RemapPermanentLinkReferences(IDictionary idMap) from the IReferenceMap. But that is maybe only me. Guess the "correct" way of solving own properties is to save the value as html/xhtml and let the the parser handle the remapping of the urls.