Enumerations: The Mapping’s Revenge

In the periods of yore, we great pioneers of Mendix waded deep into the murky depth of the modeler handling web service mappings after web service mappings. From these times came an enumeration mapper of inspired thought: Keeping Enumerations as Entities

As you can see from this article it allowed us to get away from pesky manual comparison microflows of strings to enumerations. Unfortunately this methodology has its drawbacks, first of all the enumerations were stored in the database which implies constant database queries when mapping. Now if we could only get away from this…

Well good news! today we have come with more gifts for you intrepid modelers: An alternate method for determining an enumeration from a string.

So how do we do it. Well firstly lets look at the problem, we have a few situations (xml, webservices) where we can receive a string we need to map into an enumeration. So what we are looking for is a method to input the string and retrieve the enumeration value. Now java actions and microflows only return specific enumerations, so unfortunately we cannot get away from this. However we can make an easy way to retrieve this.

So in the new method we create a non persistent entity we call “EnumerationMap”, to which we add the enumerations we wish to map.

The ext step is to create a java action which given a name for the enumeration and its value (caption or value but case sensative) can return the EnumerationMap entity populated with the found value. We can then build a nice and simple microflow which returns the enumeration as required (see below). and voila, now only one annoying entity(although non persistent) in the model and no db queries required.

To see the magic sauce inside the java action please download the example project package here (v 4.0.1)

Please let me know if there are any thoughts or queries

Widgets and IDEs

IDEs are tools that help developers to write code. When discussing which IDE is best amongst die-hard devs, it should always include “what it is best for” as well, or you will find yourself enveloped in a blazing bias flavour flamewar before you can grab a hose.

All tools are useful and serve a particular purpose, and depending on what your pragmat-o-meter reads, you will probably also have a preference which will incline you towards one tool and not the other and will make your choice invulnerable in a flavour argument. Here is my preference of IDEs as far as only Widget development goes.

Its a wise choice when choosing an IDE to include as much introspective, autocompletion, compile-as-you-code and code highlighting capabilities as possible to make you productive, especially if it feels painful if you are used to developing at the speed of Mendix. So looking at the top contenders out there, I discovered the following 2.

Eclipse

First I used Eclipse, or rather Aptanana in my case. Many of you do and probably will end up using a version of Eclipse since you might already use it for coding JavaActions. Its free, community driven and supports many plugins to help you develop your javascript. Its a very competent IDE, however support for Dojo specific introspection and code completion is lacking. This is the framework Mendix uses for its widgets.

Webstorm

“Inadequate IDEs lead to fear and frustration. Fear and frustration leads to anger; Anger leads to the Dark Side.”

My colleague, who I shall refer to as Yoda, ended up introducing me to light side of the force; Jetbrains‘ Webstorm IDE. I owe him many thanks as this turned out to be the best choice for what I needed (and more).

Jetbrains has the ability to load external Javascript libraries to provide you with code introspection and documentation. Mendix uses version 1.6 of Dojo, so thats really nice since the latest libraries differ slightly in their APIs and code support might fumble you in unexpected places. Registering this cpability was really easy.

Webstorm checks your code for syntax errors, gives you warnings for when you do stupid things and understands the way Dojo constructs its widget scaffolding. But the 1 thing I love doing with Webstorm is the ability to refactor my code, very much like Eclipse does, though better when it comes to Javascript development. I will cover a range of refactoring tips once we get a real project going.

Also, when coding widgets you might end up doing some CSS for styling your widget, which is no problem for Jetbrains’ IDE.

The down-side is you have to purchase a license, but I don’t see this as a problem, as Jetbrains is a closed-community and is championed by developers with a clear roadmap, which lends it a more focused application and direction and gives you the value for your money. Its built by developers for developers and I’ll uncover some of its secrets in future posts.

I would also like to hear your comments on which IDE you prefer and why?

Posted with Blogsy

The refactoring factor

The world we live in is fascinating and its easy to take amazing things for granted that make our lives easier.

If you have some coding experience and had to refactor some piece of working software you will probably appreciate the tools that allow you to do refactoring.

I became a Python developer after some years’ experience in Java because of its “hassle-free” dynamism that liberated me from primitive text-based IDEs and static compilers. This was until I revisited all the cool IDEs, like Eclipse, that made Java an attractive development technology again, not because something fundamentally changed in the language, but because the tools made coding much more enjoyable, like refactoring your code without breaking it.

If you are a Mendix Business Engineer you are not excluded from the fold of the fantastic refactoring forte. You probably just haven’t been made aware that you are.

Loosely stated

“Code refactoring is a disciplined technique for restructuring or altering existing code and internal structure without changing its external behaviour, undertaken in order to improve some of the nonfunctional attributes of the software.”

The ability to change chunks of  what goes on “behind the scenes”, like data models and flow logic where the end-user is unaware of these changes, is an almost everyday occurrence. Ever noticed the errors in your Error viewlet in the modeler when you’ve made structural changes, like deleting an association or adding an enumeration though not changing any interfaces? Well, this is the modeler implicitly guiding you in some cases to apply refactoring.

Refactoring in action

This past week we delivered a project for a sprint review where we had to implement a new complex widget 30 minutes before the actual review as our definition of done was in a liberal phase. The implementation wasn’t a straight forward one as the data model required to operate the new widget was fundamentally incompatible with the existing model.

Needless to say, the business modeler allowed me to make huge changes and commit it back to the cloud in 29 minutes. That was quick refactoring for that load of work. I was thoroughly impressed with this gamble and needless to say the review was positive. Now, the obvious way to solve these kind of “cutting the red wire a second before the bomb goes off” situations is to avoid them entirely, but the rule however does not cover the exceptions and exceptions occur and you have to be flexible when it happens.

One feature worth mentioning is the Extract Microflow that allows you to take a selection of actions in your microflow and promote it to a separate microflow. Its clever enough to infer what parameters are needed and pre-populates the new microflow with them, returning a value if needed. Having this kind of refactoring capability inside a modeling tool is very cool indeed:To wrap things up, here is a little video demonstrating some refactoring in action. Its a simple app that starts up with a search screen that allows you to find existing customers. If they are not found, the app creates them using the “Get-Create” design pattern discussed in an earlier post.

Note that the app should work as it did after the changes, only improving the inside guts of our system. In essence the change allows us to make a sub section of our microflow re-usable by future improvements and cleans up an existing microflow.