Help understanding Services in a GUI Extension

Question

I've been able to follow set up a simple PowerTools extension (help pop-up) following existing tools and notice most PowerTools extensions have services that support matching editor files.

For example CountItems has in PowerTools.Editor > PowerTools > Client:

• CountItems.aspx
• CountItems.aspx.cs
• CountItems.aspx.designer.cs
• CountItems.js
• CountItemsCommand.js

And in the Model side in PowerTools.Model > Services:

• CountItems.svc
• CountItems.svc.cs
• CountItemsData.cs

Is this a preferred or typical setup for an extension with multiple "tools?

Background: I'd like to (eventually) revisit the authorization tools and have core service examples to get things like publications, groups, organizational items, permissions, etc.

Would it make sense (is it possible) to offer these types of functions to other tools or should an "Authorization" extension have its own set of Model files? For example, a service that returns organizational items or publications might be useful across tools.

Some guidance showing how the PowerTools setup differs from typical GUI extensions (or simply MVC) appreciated.

Answer 1

I wouldn't really say this is necessarily a Tridion-specific question, nor would I say that the PowerTools model is the canonical (or even best) approach to architecting GUI extensions.

It sounds like your main concern is reuse of "common" service layer logic, which, I'd say, is an entirely reasonable goal. Given the scenario you describe (exposing general data access to a number of application-specific tools), my initial instinct would be to tier my application like so:

Service Layer - Responsible for retrieving and/or updating Tridion items via the core service; interfaces would include IPageService, IComponentService, IPermissionService etc. This layer provides "generic" Tridion data access capabilities with no application/tool-specific implementation details (this layer could be further split out into an additional repository layer responsible purely for making the low-level Core Service calls).

Application Facade Layer - Responsible for exposing your services to the tools that need them. This layer integrates the classes in your service layer and exposes higher-level functionality, such as, for example, setting permissions on a particular folder for a particular group, adding Component Presentations to pages, etc.

If you find at this point that you still need to abstract further, you could then create "tool-specific" services such as in PowerTools but it's certainly not a necessity if your facades give your applications everything they need.

It certainly sounds like this question is more a case of "how best shall I architect my application," than "what is the convention for doing this in Tridion," as I'd say that how you expose your web services (and how you design the application behind them) is beyond the scope of conventions in Tridion itself and into the realms of general application architecture. With that in mind, it's certainly reasonable - commendable, even - to want to expose centralised services to multiple tools instead of just bundling all of your Core Service code into the same class that serves results to the UI.