Handles are the small white and black objects that you see when you select a Figure (see next figure). They allow you to manipulate the figure by moving them around. In this tutorial, we will show you how to configure a Handle to alter the size of a Figure. We will as a base the diagram editor we were building in the previous part of the tutorial.

Handle configuration

Configuring a Handle is quite simple, basically in the initialization method of your Figure, you have to add the Handle to the handles collection it’s inherited from the Figure class. Let’s modify our SimpleRectangleFigure figure:

In this case we have added 4 handles that will look to the topLeft, topRight, bottomLeft and bottomRight properties of the Figure. If we reload the editor you can see that the Figure has the 4 handles and that if you move them around the SimpleRectangleFigure resizes itself.

Understanding how handles work

When we instantiate a Handle we pass the Figure which the Handle has to observe and a selector as a String. The Handle registers itself as an observer of the Figure so that when:

- The Figure the Handle observes is moved
It moves to a new position that is computed by sending the message to the Figure. In our first case Figure>>topLeft will be evaluated and a Point will be return. That point is used to set the new Frame of the Handle.

- The Handle is moved
The Handle sends Figure>>topLeft: aPoint to the observing Figure so that the Figure updates its Frame. One thing we have to recall is how we implement the - (void) drawRect:(CGRect) rect on: (id) context of our SimpleRectangleFigure:

Because we used the bounds of the SimpleRectangleFigure to draw, we are safe that the Handle will work when we move it around.

You can try it yourself here.
Also, the sources of the project are available here.

In the next episode we will show you how to create a more advance Handle to change the color of the Figure based on the distance to its center!

Define the visual aspects of the figure

In our case we are going to create a SimpleRectangleFigure, so we will need to draw the background of the rectangle and the border. This can be done simply as follows:

All figures come with 2 predefined instance variables for the foreground and background colors that can be configured to paint it. We will define them as black and white in the initialization method as follows:

Great! so we have our figure coded, now let’s define the tool that creates the figure.

Define the tool that creates the figure

A Tool is responsible for interpreting events/gestures and instantiating the Figure. CupDraw comes with some abstract classes that can help you create some basic tools quickly. In our example we will extend AbstractCreateFigureTool and implement a simple method for creating the rectangle with a default width and height when the user clicks in the Drawing. We implement the - (void) createFigureAt: (id) aPoint on: (id) aDrawing method as follows:

The first line creates a default frame for the given point and then we instantiate our SimpleRectangleFigure. Then we add the rectangle to the given Drawing and we active the Selection tool so that the next click is handle by the Selection tool. If you want to stick to this tool so that multiple clicks create multiple rectangles, you can remove the last line.

The last thing is to add the Tool to the toolbox in the AppController, we can do that by simply:

CupDraw is a Objective-J framework for creating graphical editors that is based on the concepts of the famous Smalltalk Hotdraw. So far, this version contains the main concepts of that Hotdraw with a few utility classes that can help you build a basic editor.

We were users of Hotdraw for desktop applications and we want to provide a port for Objective-J (as it is quite similar to Smalltalk). We are using this version to migrate most of the features of an Eclipse based editor for the WebSpec requirement language (you can see some videos of the eclipse version here). We plan to open this editor soon so that you can also be aware of the things you can do with CupDraw.

There are multiple articles (01, 02, 03, 04) talking about how to compute MD5 in Java and some of them have some gotchas regarding the length of the result. Here is a small code snippet that works OOTB:

In our previous post we explained how to work with Mule and Hibernate using an interceptor that makes every method invocation transactional. In this post we will show how to simulate the open session in view pattern (used in Web apps) for each flow.

To do so, we will assume that we have the following simple flow that receives messages from a HTTP endpoint and chains 3 services in a flow:

We want to reuse the open session in view concept for our HTTP flow. To do so, I have created 2 MessageProcessor that opens and closes the hibernate session. Their implementation is as follows:

and:

The HibernateSessionAdvice class is an adapted copy of OpenSessionInViewFilter; you can find the implementation here. The last step is to modify our HTTP endpoint to open and close the hibernate session using the previously created MessageProcessor. We modify our configuration and flow as follows:

If you are looking to use Hibernate with Mule ESB this is your place. Though Mule has a Hibernate transport, it is out date and it won’t work with Mule 3.
In this series we are going to explain different scenarios where you can integrate these technologies.

Let’s begin with something simple; suppose we are building an application that reads from a JMS queue and you would like to invoke a method in MyService Spring bean. Let’s assume we have the following Spring configuration:

and it’s implementation is as follows:

following our implementation you may try the following configuration for our scenario (assuming that the elements in the queue are long paramenters):

This implementation assumes that a Hibernate session exists for the current Thread; something typical in Web applications using the Open session in view pattern. Well in this case it won’t work because nobody has created a Hibernate session for you.

How to fix it?

There are several ways, in this case we are going to open the session and make the invocation transactional. To do so, first create 2 interceptors: a transaction interceptor and the hibernate interceptor.

Then you can refactor the Spring config as follows using the Spring’s ProxyFactoryBean:

Finally you will need to add a default constructor to be able to proxy your com.MyService class as follows:

Hope you like the post and stay tuned; we will present more alternatives to use Hibernate with Mule soon…

I guess that most of you agree with me that UI is one of the most painful aspects of building Web applications (at least if you compare it with backend development). Well if you are building a Web application using GWT you may be tempted to use SmartGWT as it provides really cool widgets. Well, that’s true, their widgets are really cool and the themes are great. However, I would like to explain my experience using SmartGWT for a personal project (a first version of the app is shown below).

First version using SmartGWT

My application is pretty basic, just a couple of forms, windows, tabs and toolbars; nothing more crazy than that. The main intent of the application is to allow people to take personal notes. The development went pretty well the first 2 weeks while I was working with the basic stuff; then I realize that I need to use a simple autocomplete field and though SmartGWT doesn’t provide an Autocomplete field OOTB I tried to use a custom solution using the ComboBoxItem; a really bad idea…

First, ComboBoxItem doesn’t work as a field in Calendars so big problem; lucky I found a workaround to fix the issue. Then I tried to make the ComboBoxItem’s datasource work with a remote GWT call though SmartGWT doesn’t provide a OOTB datasource that works with the GWT paradigm. Again, a big mess digging into the javascript code where SmartGWT is implemented

Ok, so let’s try to fix the autocomplete problem using the SuggestBox that GWT provides OOTB. Well, another bad idea as SmartGWT randomly works with GWT and they clearly mentioned in their docs that it is not recommended to mix both.

Finally let’s try to extend the framework to make it work in either case. Well, here is the main issue I found with SmartGwt: the GWT UI classes that they provide delegate most of their behavior to plain javascript that is inside the JAR file. Oh my God, how do you expect developers to extend your framework?

The answer may be: either open the jar and do it yourself or move to Smart GWT Pro (license based). Open the jar or extending at the javascript level lowers the level of abstraction and that’s something I don’t want and the main reason I’m using GWT and not jQuery.

I’m my case it is ridiculous paying for a license and I must say that I’m used to the business model that other open source products have (e.g. Mule, Spring, Hibernate) that you pay for support though you are able to extend the framework easily.

A small suggestion from a disappointed engineer: you have one of the best GWT UI libraries in the market that look perfect and your widgets are really cool, don’t screw it up with this mix which is NOT easy to extend.

At the end, I tried for a couple of days to implement a workaround, the solution was not stable enough to be used in a real application. I end up implementing a basic window and toolbar in plain GWT using GWT Drag and Drop and reuse some of the SmartGWT styling. The results are shown below; now I have an extensible solution that I can fix in case of problems but with the overhead of having to fix it myself .

It is pretty common that you may need to add/extract attachments when working with SOAP based Web services (WS). In this short blog post we explain how to do it using Mule’s CXF module.

Receive and extract attachments

When you are receiving a SOAP message, the first thing you must know is that Mule does not copy SOAP attachments to your Mule message. If you want to do so, you will need to add a special CXF interceptor to do it (CopyAttachmentInInterceptor). The next code snippet shows how to add that interceptor:

All the attachments are copied to the cxf_attachments INVOCATION property of the message. Notice that the value of that property is a COLLECTION of attachments. To work with attachments you can use the expression transformer, for example the following code snippet extract the contents of the first attachment of the list and sets it as the current payload of the message:

Add attachments and send

On the other hand, if you want to send attachments to a WS you will need to create the cxf_attachments property and then use the CopyAttachmentOutInterceptor interceptor to copy those attachments to the SOAP message. The following code snippet adds an attachment and calls the WS:

The AddAttachmentMessageProcessor class is responsible of creating the attachments collection and set it in the cxf_attachments property. The class itself is pretty simple, just adds the attachments as a property of the message:

Activiti is a light-weight workflow and Business Process Management (BPM) Platform targeted at business people, developers and system admins. However, its standard version doesn’t allow to integrate with your existing enterprise technologies (e.g. your JMS broker). In this post we will briefly explain how to integrate Activiti with JMS using Mule’s Activiti Module.

First, you will need to run Activiti in embedded mode inside your Mule application; it is pretty similar to run Activiti inside Spring. An example configuration is shown next; you will need to define your processEngineConfiguration and the service beans you can obtain from it:

Then you will also need to define your JMS broker; in our case we will use Active MQ:

Finally, your Mule’s Activiti connector:

We are ready!
For our example, let’s suppose we have a process for managing orders that waits for the approval of a manager:

The manager approves them by submitting a message to the JMS queue approveQueue. To resolve which process needs to be approved the message must contain the process id and the username which will be set in the approvedBy variable. For the sake of conciseness, we will create the process from Mule as shown next:

This process will start and wait for a message in the JMS queue to signal it. This can be easily solved from the Mule side by specifying a flow that reads from a JMS queue, sets the variable approvedBy and signal the process as shown next:

Salesforce is the cool CRM who is starting to be used in almost any organization. Sadly for us (the developers) we will need to integrate with it soon. If you are using a BPM like Activiti, you may need to integrate sooner as the growing demands of business people. In this post we are going to show how to create a Salesforce contact from your Activiti process using the Mule’s Activiti module and the upcoming version of Activiti 5.6.

In our case, we will simulate that we need to create a Salesforce contact from our Activiti process. We will perform this task by calling a Mule endpoint and passing the necessary information as shown next:

The sendTask invokes the mule endpoint vm://createSalesforceContactFromActiviti which will receive the message with the necessary information to create the contact:#{firstName},#{lastName},#{email},#{title},#{phone} (where #{firstName} refers to the value of the variable firstName in the context of the process). Then we need to define the endpoint in the Mule’s side; the flow is simple and is shown next:

The sfdc:create type=”Contact” tag is the one that executes the contact creation in the Salesforce account. This information is stored in the payload of the message and need to be splitter (as it is comma separated) and then stored in the message’s headers so that we can reference them using: #[header:OUTBOUND:FirstName]. To do that we code the custom message processor SplitAndSetFieldsProcessor: