Base Processor - exposing Umbraco context services

[leekelleher]

From reading Umbraco core's recent Common Pitfalls & Anti-Patterns document, should we consider exposing the Umbraco objects via our DittoProcessorAttribute? (rather than letting developers use the static singletons)

Of course, under the hood we'd actually be exposing the static singletons, (since this is how Umbraco core do it - e.g. SurfaceControllerFactory.cs; not using dependency injection), this would encourage developers to use our exposed properties, so in future we could potentially replace/inject them (or however Umbraco core team recommend we package devs should do this).

Based on the doc, (and the Umbraco core's PluginController code), we could expose the following properties...

• ApplicationContext
• UmbracoContext exposed as Umbraco
• DatabaseContext
• ServiceContext exposed as Services
• MembershipHelper exposed as Members
• ProfilingLogger / Logger

re: UmbracoHelper - we shouldn't need to expose this, as it is typically used to retrieve from the content/media cache, whereas we can use UmbracoContext.ContentCache.GetById directly.

---

Any thoughts?

[mattbrailsford]

Agree 👍 Let's do it

…

On 6 Jan 2017 6:45 p.m., "Lee Kelleher" ***@***.***> wrote: From reading Umbraco core's recent Common Pitfalls & Anti-Patterns <https://our.umbraco.org/documentation/Reference/Common-Pitfalls/> document, should we consider exposing the Umbraco objects via our DittoProcessorAttribute <https://github.com/leekelleher/umbraco-ditto/blob/develop/src/Our.Umbraco.Ditto/ComponentModel/Attributes/DittoProcessorAttribute.cs>? (rather than letting developers use the static singletons) Of course, under the hood we'd actually be exposing the static singletons, (*since this is how Umbraco core do it - e.g. SurfaceControllerFactory.cs <https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Mvc/SurfaceControllerFactory.cs#L56>; not using dependency injection*), this would encourage developers to use our exposed properties, so in future we could potentially replace/inject them (or however Umbraco core team recommend we package devs should do this). Based on the doc, (and the Umbraco core's PluginController code <https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Mvc/PluginController.cs>), we could expose the following properties... - ApplicationContext - UmbracoContext exposed as Umbraco - DatabaseContext - ServiceContext exposed as Services - MembershipHelper exposed as Members - ProfilingLogger / Logger re: UmbracoHelper - we shouldn't need to expose this, as it is typically used to retrieve from the content/media cache, whether as we can use UmbracoContext.ContentCache.GetById directly. ------------------------------ Any thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#200>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgLyWRh7A-_bHher4rCmLVUjQkmrTgIks5rPovXgaJpZM4Lc_WR> .

[JimBobSquarePants]

Yup. Definitely wise.

[jamiepollock]

Late to the party, but this would be awesome. :)

[mattbrailsford]

Shall we close this and move the discussion to the PR?

[leekelleher]

Onwards to #204