A large problem with Sitecore PowerShell Extensions up to version 3.0 was the lack of proper separation of solutions provided on top of it from the core of the module. The problem is that all integrations look for scripts in the main Script Library but they look for them solely in their single libraries. The specification outlined in this blog aims at solving this issue.

The current structure of the tree looks somewhat as follows:

The libraries allow you to add your scripts e.g. to the Content Editor ?> Context Menu library but this gets pretty messy pretty fast and if you want to share your cool solution with your peers you need to carefully cherry-pick your items to create a package from them.

Now once your colleague installs the solution:

• they have no easy way of telling what scripts went where and what was added.
• if they want to remove it – it?s not easy to tell what should they deleted as you might have put some items it the Functions library and a question like: ?is that Content Editor -> Context Menu script self contained or is it launching a script that?s stored somewhere else?? is impossible to answer without carefully examining each script code.

We have the same problem within the module itself. We add cool solutions to context menus like Copy/Paste Renderings or Package Builder which – while they demonstrate the amazing flexibility of the PowerShell Extensions module ? they pollute the core with unnecessary scripts that are going to be used very occasionally or cause confusion to our users. In fact all of our solutions should also be packaged into modules to enable for removal or disabling of functionality with much more granularity. Please find the proposed new organization of the library:

In this new structure for each module it would be possible to hold its own version of the library. Which means it would be possible to tell the bounds of each solution. It would also enable us in the longer term to add support for modules in ISE where not just a single script would be the focus of your work but rather the whole module at once. The location of scripts used by integration points would still be determined by the naming convention, just like it is now, it?s just that instead of looking in a single library it would instead search inside of each module.

A module item data template would roughly look as follows:

Which would allow for the scripts author to have their credits exposed for the great work they did providing the module.

What I would like to see is for most of our existing core scripts (maybe apart from basic scripting tutorial examples) migrate into modules, and in the long run we would require everything to be packaged into modules.

I strongly believe the current organization of the script library is unmaintainable in the long run and without the proper modularization we?re going to hit an adoption wall (if we?re not hitting it already). We?re running into this problem daily in Cognifide and e.g, it is not possible for me to maintain the Console as part of a Zen Garden deployment as we have plenty of scripts in there mingling with the PowerShell Extensions core scripts.

Having the modules infrastructure in place it would be possible to create a marketplace for scripts modules where people and the core team could post modules and scripted solutions for Sitecore users to download, (potentially even have some of those available for a small fee with a revenue share model).

The benefit of this would be pretty obvious but let me iterate anyway:

• Give proper exposure to solutions like Package Generator or Copy/Paste renderings
• Allow for better modularization of SPE and having a lean solution as a core.
• give exposure to people that would write such scripts but have no proper vehicle to distribute those.
• Even the core team does not publish separate script packs so how an external developer would know what is the canonical way to distribute those?
• Allow ISE to work with modules rather than single scripts.
• Allow developers to be able to monetize their hard work in the later phase.

Now how those modules would be published remains to be seen ? ideally those would be available on Sitecore Marketplace if Sitecore would be so gracious to create a section for us, but that is a secondary issue.

What do you think? Your comments really matter!

(No Ratings Yet)

Loading...

This entry (Permalink) was posted on Saturday, November 1st, 2014 at 11:35 am and is filed under .Net Framework, ASP.NET, Best Practices, PowerShell, Sitecore, Software Development, Web applications. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response , or trackback from your own site.