Blocks was developed by:
Deane Barker
Blend Interactive
deane@blendinteractive.com
http://blendinteractive.com
Blocks is licensed under the LGPL. Do want you want with -- including using it other commercial software -- but release your changes, please.
If you make change or improvements and you'd like to see them make it into the "official" codebase, send me your changes.
There is none. Blocks is absolutely "use at your own risk" software. We've had great luck with it, but we provide zero warranty. For all you know, it might melt your server and steal your children. It's a risk you need to be willing to take.
Blocks is utterly unsupported by Ektron. I doubt that using it will void your support or anything, but understand that no one at Ektron is going to debug your Blocks issues. (On second thought, I'm not willing to guarantee that Ektron won't void your support, either.)
Blocks enables you to resuse common functionality to extend Ektron. It presents a framework that executes as part of Ektrons event model. This framework processes a configuration file which executes pre-written "blocks" of code (hence the name). To create a new piece of functionality, you can simply stack and re-arrange existing blocks, or write new ones and plug them into the framework.
(The architecture of blocks turns it into an "extensible extension" or a "pluggable plugin." An irony not lost on the author.)
Compile the DLL from source and put in your extensions directory.
Since Ektron's extensibility model fires on every action in any install on a given server, Blocks will fire every time, across multiple sites. The first thing it does it check for a "blocks.config" file in the site's root. If it doesn't find one, it exits. If it does, this signals that Blocks is enable for this particular site and should be processed.
The configuration file tells the Blocks engine what content to act on. The config file us divided up into "Profile" blocks. These blocks are a single, logical functional unit. When activated, the profiles will be processed, in order. Each profile is independent. A publishing action can trigger no profiles, all the profiles, or anything in between.
Each profile has four child elements.
Reviewers tell Blocks if it should do anything with this partcular content item. Each reviewer is asked, in turn, "Should Blocks do anything with the content that just fired the event?" If any of the Reviewers return "true," the remainder of the profile will execute.
It's important to understand that the system fires on every publish, no matter what. It simply iterates through all its profiles, and only does something if a Reviewer in that profile returns "true."
PublishFilters operate on the content item. They iteratively and cumulatively modify the content before the PublishActions execute.
PublishActions run during the OnAfterPublish event. They have access to the content with the cumulative modifications of the PublishFilters.
DeleteActions run during the OnAfterDelete event.
Putting it all together, the profile below would:
<Profile Name="Publish Privacy Policy"> <Reviewers> <ContentId Id="32"/> </Reviewers> <PublishFilters> <AddTimestamp/> <ReplaceString Find="http://dev.mysite.com/" Replace="http://mysite.com/" /> <ProcessTemplate PathToTemplate="C:\Templates\BasicPage.tpl" /> </PublishFilters> <PublishActions> <ModifyFileSystem Operation="Write" Path="C:\Site\Root\" FileName="privacy-policy.html" /> </PublishActions> <DeleteActions> <ModifyFileSystem Operation="Delete" Path="C:\Site\Root\" FileName="privacy-policy.html" /> </DeleteActions> </Profile>
The profile below would:
<Profile Name="Warn Deane"> <Reviewers> <ContainsText Scope="Title" Text="Deane"/> <ContainsText Scope="Html" Text="Deane"/> </Reviewers> <PublishActions> <SendEmail To="deane@blendinteractive.com" From="noreply@blendinteractive.com" Subject="Someone is talking smack about you..."/> </PublishActions> </Profile>
Blocks was designed to be extended. The elements in the Reviewers, PublishFilters, PublishActions, and DeleteActions elements simply map to classes which implement certain methods.
Each of these classes contains an "Execute" method which is invoked in turns as Blocks progresses through its configuration file. To write a new reviewer, action, or filter, simply write a new class, name it the same as the element in the configuration file, and implement an "Execute" method.
So, as Blocks starts working through its configuration file, if it finds the following block --
<Reviewers> <ContentId Id="32"/> </Reviewers>
-- it simply instantiates a class called "ContentId" from the "Blend.Ektron.Plugins.Blocks.Reviewers" namespace. Then it calls the "Execute" method on this class, and passes it (1) the content object, and (2) the configuration information. In the case of a Reviewer (as presented in this example), Blocks reads the response (a boolean) to tell it whether or not to process the filters and actions in this profile, or whether to skip it and move on.
The "Holy Grail" of Blocks, and the thing that would make it live up to its full potential, would be the ability to run code across DLLs. This is what was originally planned for it, but I couldn't get it working, no matter how hard I tried. This problem was the source of this post to Stack Overflow:
The problem is, as yet, unresolved. If we could solve this, then people could distribute new reviewers, filters, and actions as discrete DLLs that people could plug into their Blocks frameworks. This is really the ultimate goal.