Shame on you Mr EPiServer

Have started to investigate some mirroring issues @GarethKelly have reported regarding Itera.MultiProperty. But pretty soon (after I got the damn mirroring stuff to work :) )  I discovered that the mirroring service don’t just look at the IReferenceMap but also on the type of the property.

To get mirroring to work you need to (as muhammad kashif pointed out) copy your dll’s to the subfolder MirroringService\bin

I thought that if I made a reflector copy of PropertyUrl that copy should behave exactly the same as PropertyUrl. That is not the case regarding mirroring.

I tested this with creating a page with the 2 properties, and got these results.

PropertyUrl

Page:

Mirrored page

Reflector copy of PropertyUrl

Page:

Mirrored page

Strangly is that if I fill out the same values on the source page, the mirrored pages properties points to the same document (the correct)

Why is it like this?

If we do some reflectoring, we can se that there are special handlers for different kind of properties

So I though, great, I can make my own, but as far as I can see this stuff is registered inside DataExporter

This is extremely bad news for every developer of EPiServer that want to create custom properties. This makes mirroring a bit hassle.

One solution the overcome this shortcoming of mirroring 2.0 we could create a PropertyXhtmlString property on each page where we automatically add a href to each element from the IReferenceMap. But that would be counter productive.

There shouldn’t be any difference between a Reflector copy of PropertyUrl and PropertyUrl!

Is there anything I have overlooked Mr EPiServer :) ?

Added some thoughts 30. sept

After a god night sleep, I have thought some more about this mirroring issue,

In my opinion the first problem is that the mirroring service need to know the properties (have a copy of the dll’s) This approach have already given me problems with auto attaching virtual maps and other stuff. Its like that a telecom operator need to know what kind of person you are to be able to transmit your voice.. Its shouldn’t be like this at all.

Common, you have added a change log construction. That construct could have taken care of your extra needs. There is also already in place a SoftLinks construction (that could need some love) that could have provided you with what resources a page reference to.

The other problem is that before all properties had 2 sides. One data container side, and one display/edit side. With the stuff in the DataExporter you have introduced a 3. side. And left us developers with (as I can see) any methods to add code to this side. In the past you (Mr EpiServer)  have been reluctant to change code since it will break existing project. This new code breaks that rule big time.