Recent Posts and Articles
Orchard 1.4.2 is a service release that fixes bugs in 1.4 and 1.4.1. The list of bugs fixed in this release can be found here:
Bugs fixed in 1.4.2
Please consult our release notes here:
Orchard 1.4.2 can be downloaded from Codeplex today, and soon from WebPI:
As an Orchard Developer there are times you need to access an asset within the current Orchard Theme Folder from a view. Since the current Orchard Theme can be easily changed by the Orchard Administrator on the fly, you obviously can't hardcode a path. You need some way of programmatically determining the path to the current Orchard Theme. As with most things in Orchard, there is an HTML Helper for that.
The Orchard Developer Team released Orchard 1.4.1 on May 4, 2012. Orchard 1.4.1 is a maintenance release and fixes/closes at least 57 bugs/work items and has all the new features from Orchard 1.4, including: Autoroute and Alias, Projector Module, and numerous new field types. In addition to those main features in Orchard 1.4, there are numerous other changes like Custom 404 Error and Not Found Pages in Orchard, displaying edit and content links in Orchard, Orchard datamigration classes automatically being updated, and more.
Ah forms, the bane of a web developer's existence! That and trying to get IE to play nice with your CSS of course. Forms should be easy right? But they're just consistently tricky enough to build from scratch each time and most web developers simply end up keeping a stash of templates handy that they can just reuse.
Well, this tutorial aims to show you how to create reusable forms inside the Orchard CMS back-end made up of the already reusable components built into the core of Orchard. Not only does it take away the pain and drudgery of having to create and test forms in HTML code, but also, should you require, you can dip down to "the metal" in places where you require more control.
We'll cover all of these things here while building a form with the upcoming Orchard Custom Forms module, adding it to the site as both its own landing page, or a widget you would like to plugin to numerous pages, followed by hooking it up with the Orchard Rules module to fire an email out the door based on the rich extensible eventing all built in. Oh, and we'll throw in a bit about permissions as well to show you that security is not an afterthought.
In a previous post, I discussed how to create and work with a CMS web site using WebMatrix. In this post, we will discuss how to deploy the website to a hosting account.
It probably makes sense that my first official blog post for my fresh start is on Orchard CMS since I currently spend a big portion of my day developing Orchard Websites, Orchard Modules, and Orchard Themes. This particular post is based on my own experience with the new Autoroute Part and Alias in Orchard 1.4 as well as a question I received from a client today. My client was changing the permalinks on published content items in his Orchard Website and noticed the website was still responding to the old permalinks. His question was fair - how do I remove the old permalinks from the Orchard Website?
Although Autofac is not really part of Orchard's public API, it does come in handy when you need to customize how some of your classes are created and managed by Autofac.
In general, when you write your own classes that are injectable, you would take the following steps:
- Define an interface that derives from IDependency;
- Define a class that implements your interface
However, in certain cases, you may want to inject concrete classes directly into your constructor instead of an interface. One example might be when you implement the Command Pattern. You would generally have multiple classes that ultimately implement some ICommand interface. Next, consider having a controller that has a dependency on some command, e.g. SaveCustomerCommand. One solution could be to create a specific interface for each command, which would be perfectly fine (and perhaps even preferrable for unit testing classes that depend on these commands). But let's say that for some reason you don't want to write these interfaces. How would you be able to inject an UpdateCustomerCommand or a SaveCustomerCommand?
The answer is to tell Autofac about it!