ItemWrapper.Original as Item

[Thomas Delplace]

Hello,

Is there a particular reason why the Original property of the ItemWrapper class returns an object instead of a Sitecore.Data.Item ? The underlying private field is an item...

Thomas

[Jason Bert]

Hi Thomas,

The idea behind this was that we didn't want to expose any Sitecore APIs or types. If we returned the Item class on this property then it would make the interface a lot more difficult to mock. The property was put in to provide a way to get the Item out as a kind of "last resort" if you really needed to gain access to it.

Best regards,

Jason

[Thomas Delplace]

I understand the idea behind.

The thing is I'm stuck here with a non-mvc Sitecore 6 implementation, and I wanted to use the <sc: Sitecore controls, and I need to pass it the original Item object. I will wrap it in my CustomItemWrapper to make it easier...

Thanks,
Thomas

[Benjamin Vangansewinkel]

If it is for unit testing your framework, why don't you use https://github.com/istern/Sitecore-Fakes to mock your Sitecore item?

Regards,

Benjamin V.

[Pavel Veller]

Better yet https://github.com/sergeyshushlyapin/Sitecore.FakeDb

:)

Sent from my iPhone

On Jun 16, 2015, at 1:36 AM, VGBenjamin [e-mail] wrote:

If it is for unit testing your framework, why don't you use https://github.com/istern/Sitecore-Fakes to mock your Sitecore item?

Regards,

Benjamin V.

—
Reply to this email directly or view it on GitHub.

[Jason Bert]

@VGBenjamin - the primary goal of the framework was to encapsulate the Sitecore API and not expose it. When I mentioned about unit testing it was more about making the interfaces unit testable for the user of the framework. Exposing the Item class means you would need some kind of system like those mentioned, adding more dependencies to your project.

This isn't to say those systems aren't good or useful :). They're good systems if you're using the Item the class through your project.