If you have been following our blog you know that we have been working rigorously on Mura 5.2. Very exciting stuff - we're introducing lots of new features and capabilities.

One of the most important new aspects of Mura CMS are new ways to interface with Mura both on a remote level as well as internal (event) level. This does not mean that you need to change your current code, so don't worry (as always, we strive to keep Mura CMS backwards compatible), but there will be a lot of new functionality available within this and future versions of Mura CMS for programmers.

One of these changes is the focus on using a new method that is provided via the Mura event. This method is called getBean(). It's quite similar to common calls to Coldspring defined components for Mura (example: application.serviceFactory.getBean()) but it's been slightly enhanced. What that means is that the functionality is the same as before but now there is Mura logic wrapped around the getBean() method call. An example of this functionality is the auto-injection of your siteId for components that may require it. This was a no brainer for us since this "should" be hidden away as much as possible since most of the time you would be developing within the site that you are already in. I quoted "should" because there could always be that case where you are in one site but you need to gather some information from another site. No problem. The second argument to the getBean() method call accepts a siteId which overpowers the original siteId assigning logic.

Now for the exciting part. Below are a few examples on how you can interact with getBean(). I would show all the possible use cases on how you could use getBean(), but we at Mura believe that in time more and more ideas will come from the team and the Mura CMS community, so let's at least get the basics out first.

Pre v5.2 approach:

Here is how you would create an empty bean:

<cfset user = application.serviceFactory.getBean( “UserBean” ) />

Here is how you would load one up:

<cfset user = application.userManager.readByUsername( “Username”, siteId ) /><cfoutput>#firstname: user.getFname()##lastname: user.getLname()#</cfoutput>

Here is how you would update/save it:

<cfset user = application.userManager.readByUsername( “Username”, siteId ) /><!--- let's create a new record ---><cfset user.setFname( "My Firstname" ) /><cfset user.setLname( "My Lastname" ) /><cfset user.setEmail( "myEmail@somewhere.com" ) /><cfset user.setUsername( "username" ) /><!--- let's save the record ---><cfset application.userManager.save( user ) />

Here is how you would delete it:

<cfset user = application.userManager.readByUsername( “Username”, siteId ) /><cfset user = application.userManager.delete( user.getUserID() ) />

Post v5.2 approach:

Here is how you would create an empty bean:

<cfset user = event.getBean( “User” ) />

Here is how you would load one up:

<!--- get a fresh bean ---><cfset user = event.getBean( “User” ) /><!--- load it from the database ---><cfset user.loadBy( userId:"0655DC32-C8FE-494D-98FC593D387A88BC" ) /><cfoutput>#firstname: user.getFname()##lastname: user.getLname()#</cfoutput>

Here is how you would update/save it:

<!--- get a fresh bean ---><cfset user = event.getBean( “User” ) /><!--- load it ---><cfset user.loadBy( userId:"0655DC32-C8FE-494D-98FC593D387A88BC" ) /><!--- set attributes ---><cfset user.setFname( "My Firstname" ) /><cfset user.setLname( "My Lastname" ) /><cfset user.setEmail( "myEmail@somewhere.com" ) /><cfset user.username( "username" ) /><!--- save it against the database ---><cfset user.save() />

Here is how you would delete it:

<!--- get a fresh bean ---><cfset user = event.getBean( “User” ) /><!--- load it up ---><cfset user.loadBy( userId:"0655DC32-C8FE-494D-98FC593D387A88BC" ) /><!--- delete it from the database ---><cfset user.delete() />

As you can see we've removed the direct call to the application scope, serviceFactory as well as the appropriate manager. We felt this was important as these are aspects of the application that you should not need to really worry about. You should just need to ask for something and get it! We've also remove the "Bean" extension from the bean name.

At Mura we always strive to make life easier for developers and users alike. Providing a simple approach to communicating with Mura seemed like a quick win for us.

These types of wins will help you and your company accomplish more in a shorter period of time as well as help us bring down the learning curve on how to use Mura in general.

Here are a few getBean() articles that we will be publishing in the near future.

• getBean() Part 2: Saving Display Objects

• getBean() Part 3: Getting extended information about a content bean (comments, etc)

• getBean() Part 4: Binding events to beans

• getBean() Part 5: How to extend into Coldspring

As we show you more on what you can do with getBean() we encourage you to contribute your own ideas on what a method such as this could be used for getBean(). You never know - we could implement it! Please give us your thoughts, as we are really looking to the community for feedback and requests on these new features.

----------------------------------

Pat Santora
Team Blue River