In the View of Many

I’m a big Matrix movie fan. In the first film one of the characters, Cypher when looking at the Matrix code says “The image translators work for the construct program“. That’s always stuck in my mind when I get stuck into deep Microflow and Entity modelling.

In an on-going project we had to put logic inside Microflows that accesses a fairly big number of Entity models. It’s easy to get confused when faced with that perceptual complexity. Furthermore it can be tedious to tab between the Microflow and Entity model to visually reference things unless you know the 3 points below:

1. Dragging Screens

Mendix allows you to drag screens into a custom view. That means that you can have a setup where you can see 2 Microflows (or a Microflows and an Entity model) on the same screen. This setup allows you to visually see things on a single screen that you normally would have to tab to.

To set this up simply click on the Microflow tab heading you want to see in parallel and drag the Microflow. The below dialogue should immediately display. Just place the Microflow in the screen hemisphere you’d like to see it in.

Creating a Secondary View

That will result in the view below, allowing you to see both the Entity model and the Microflow in a single screen.

View of the Microflow and Entity Model

2. F11

The above setup can lead to screen real-estate issues. As posted in a previous post F11 is the answer here. It strips away all the other windows leaving on the Microflow pane in full screen mode. Exactly what you need when zoning in on more than 1 Microflow at a time.

3. Control-G

Visually removing all other sections on the screen, especially the Project Explorer means that finding some Microflows or Entities can seem tougher. Also covered in a previous post Control G brings up a dialogue allowing you to quickly search for the Microflow you need next.

By sharing screen real-estate between more than 1 Microflow we were able to complete our complex tasks quicker.

Where the Widgets’ Things Are

Widgets can be wild if you have never encountered them in their “native” habitat before, but once you’ve learned the knack of assembling them, it becomes quite fun. All you need is a little guidance.

“Where to begin” is a good question to ask yourself before you start. For which the answer you don’t have to pay the steep schooling fees of “learning by your own experience” for, as learning from others’ experience is far more profitable.

In my experience, it was overwhelming in the beginning. You don’t know quite where to focus your attention first to get the most out of it. If you are like me, you’ll be slightly more inclined to be pragmatic and want to learn by examples rather than first following the formal theory. If however you want to get your toes wet real quick, get some direction or you will most likely write dirty code that you will throw away the moment you are done with it. So lets see what we need for our adventurous embarkation.

You need some basic Javascript experience or have at least 1 language under your programming belt. Thats pretty much what is required for a start. That and obviously an idea; it helps if you know what your widget will do, otherwise you’ll just be pecking about senselessly amongst the sea of information.

Now that you have some Javascript savvy and you know what you’d like to craft, you are now going to want the following documentation open for reference:

• Version 1.6 of the Dojo documentation. I strongly recommend you master or bend your brain around dojo.hitch and dojo.partial. This is critical for meaningful event handling and callbacks. dojo.query and all the other basics are required, but demands less ramping up. There are some functional aspects to the toolkit which you might want to understand. So take your time on this bit
• Then you might find the Mendix client-side API vital to your expedition
• Mendix’ Widget XML reference guide for practical examples and how-to documentation
• The Widget XSD is the schema that Mendix uses to validate what you put into a widget’s declaration
• Lastly some example XML schema. Is invaluable to start from some other example.

These are the basic references we’ll need before we touch a bit of code or sort out our tools.

Stay tuned for our next episode on widget development for Mendix.

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.

Shrink-wrap your widgets and themes on demand

If you are fortunate to develop on a Mac or *nix system and run your Mendix project on a shared folder with your Windows VM, there is a little bash script you can use to compress your widget- or theme-artifacts as they change. I’m sure there are other ways of doing this on a Windows machine, and if you know of a suitable approach, please let us know.

The first step is to put your code folder somewhere outside of your project, since you don’t want to commit this to TeamServer™. If you do, use your SVN tools to ignore that folder for the purposes of development. After you’ve set it up, launch your IDE.

I use Appcelerator’s TitaniumStudio™  as my preferred editor when writing JavaScript, in conjunction with FireBug or Chrome’s developer tools for the interactive command prompt. This is handy for real-time prototyping and then using those changes in your editor.

The problem I find is, every time I make small adjustments to my code, I have to compress the files back into a zip-file and restart my modeler to see the effects. The same actions apply to theming. You make minor CSS changes and the ritual of compressing restarting repeats.

I Googled around to brush up on bash scripting and I wrote a little looping bash script that executes a command every second, making sure my widget or theme package is always up to date. Here it is, continuous.sh:

#!/bin/sh
cycle() {
 while [ 1 ] 
  do sleep 1
  eval $*
done
}

Then you automagically shrink-wrap your package by running:

$ ./continuous.sh “zip -r -u path-to-your-widget/MyWidget.mpk path-of-widget-files-folder/*”

Now every time I make a change to my code, the archive gets updated automatically. I’m not a command-line wizard, but this does the job for me. All I need to do now, is restart my modeler. One day hopefully, I’ll be able to automate this too.

A video explains it a bit better if you have trouble following along: