Adding custom functionality to both Sitecore Desktop and Editor was fairly easy too; we worked with Content Editor’s Ribbon and its Commands (buttons in Ribbons). The minutes passed quickly and the complexity of the drills increased, we added events to trigger actions such as classify items in folders based on any of its fields like a date or text. One of the most interesting learnings was how easy are the parameters managed between events; by using the ExtractParameter function you can get the event as an item from the EventArgs and with the help of ItemUtil class you can add new items based on the template. In the same way you can add interaction with the content editor adding Warnings Rules and overriding Sitecore’s HttpRequestProcessor behavior by modifying the pipelines.
The last part of the training was focused on extending the Command functionality. The QueryState was overridden to modify Sitecore Content Editor. Adding a few lines, the command button was enabled or disabled according to the item’s template, name or type. Then we moved on to user interactions implemented using the Sheer namespace and client pipelines; the first step was to extend Command class behavior. The Execute method was overridden to create the parameters for the pipeline. The customized parameters collection was created as new instance of NameValueCollection in the Execute method. At the end, the new pipeline was started by executing the Context.ClientPage.Start method receiving the paramaters collection as a parameter.
In order to start a pipeline three parameters are required: the object which is starting the pipeline, the name of the method that will be called and the parameters as a NameValueCollection object. For the next step we created the implementing method for the pipeline which is conventionally named Run. It’s important to remark the NameValueCollection is sent to the pipeline inside a ClientPipelineArgs; moreover Run method receives the ClientPipelineArgs object which contains, in the attribute named Parameters, the items of the NameValueCollection.
The Run method is executed every time the communication between server and client occurs, so it’s important to identify if the Run is part of the page’s postback. If the Run is called from a postback, the ClientPipelineArgs object can provide us the result of the interaction with the client as the Result attribute. Besides Result and Parameters properties, ClientPipelineArgs object has some other interesting functionality like WaitForPostback , HasResult, IsPostBack and some other method to test pipeline’s status (aborted, suspended, etc)
During the whole pipeline process, SheerResponse gives Sitecore a powerful set of tools to interact with the user: input boxes can be shown to collect data or message boxes can be displayed simply by sending the text to the SheerResponse.Alert method. If you were asking for the purpose of the WaitForPostbak, now that the input method is mentioned, it’s easy to infer how to wait for user interaction when an input window is displayed. The same way you can modify page’s HTML using Ajax or display fancy boxes: YesNoCancel, Question or Error dialog boxes.
At the end of the day, our last minutes were spent experimenting with Scheduled Tasks and Archiving, interesting and helpful features that will be covered in a future article. It was a hard day with tons of knowledge and tips but most valuable was all these hours of real hands-on practice. Every chapter we covered brought me ideas about how to implement or improve my current project’s tasks; it also helped me to understand how was working some Sitecore features developed previously I joined the project... I figured out the trick behind the magic.