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

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.

7 Hotkeys of Highly Effective People

Clicking is sometimes a drag, especially when you are on fire. You don’t want to break your momentum by taking your hands off of the keyboard to invoke some action on the screen. You need hotkeys.

I’ve watched releases of the modeler carefully, and now and then a new hotkey sneaks in without huge fanfare. Here are some that my fingers find most handy.

F5, Run Baby Run

I develop on a Mac, and leverage many of its tools, and the command-line is one of them. Sure not all Business Engineers will be power users, but sometimes you’ll find some Business Engineers need a little more umf now and then. For instance, when designing themes for Mendix, I need to make minor adjustments to my theme and apply it real quick back into the zipfile. After making these changes I cmd-tab to my terminal, hit the “up” key to get my last zip bash command, then cmd-tab back to my Mendix modeler, and hit F5. This gets repeated frequently if my design changes with many little iterations. Better yet, let me just show you 1 iteration. Notice the mouse cursor stays in one place.

Shift-F5, Stop

What goes up, must come down. Use Shift-F5 if you need to stop your server. You’ll probably use this infrequently.

F2, Garden-Variety Rename for Windows

This is a bit redundant, since you can start typing away at captions in your microflows or widgets on your forms. The only time this will be useful, is if your properties pallet has focus on another field than the Caption field.

Ctrl-Left & Ctrl-Right, Moving stuff

This one I absolutely love. Entities with lots of attributes generate grids on forms that contain a horde of columns and search fields. If only there was a way to sort them quickly. Talk is cheap. Lets see it in action.

F11, Maximize and Restore

And as you’ve seen in the previous video, F11 is a must if you work on a screen with little real estate. Use this key to maximize your workspace.

Ctrl-G, Goto Artifact

This one is handy if you know what artifact you want to navigate to within your model, without hunting for it in the Project Explorer.

Another handy trick, is using the Mouse’s middle button on the microflow canvas. Its helps you pan your view, and using the mouse wheel, helps you zoom in and out if you don’t use a Magic Trackpad™.

Productivity is like Formula1 racing. Every little improvement helps, even if it contributes a 1 or 2%. Once you try hotkeys, you will find your ergonomics improve, your fingers do the work and helps you move with incredible ease through your modeling routine letting you focus even more.

I’m burning to see more hotkeys in future versions of Mendix.