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.

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:

Enumerations as Entities

Enumerations within most normal languages are annoying to maintain and build logic off of. In most cases I have seen String variables or manually mapped integers being used. My experiences within the system analysis, database and business intelligence combination always led me to using database table entries with business logic attributes, although convincing the developers of their benefit was not always an easy battle. But, more on that transition in another post. So in comes Mendix with a more formal, easier-to-combine into business enumeration. But as we all use them on a daily basis (or at least should be) I won’t go into diatribes about their benefits, proper usages and so on. Instead this article will revolve around a Java function entity combination we use to get around the two issues we have had with enumerations.

The first common issue we faced was associating attributes with an enumeration. Creating an entity with the enumeration as a unique attribute solves the issue. However, the problem comes in maintaining this entity when creating new enumeration values particularly across multiple environments.

The second issue we are commonly faced with is mapping web service string results into enumerations (A nightmare for anyone who has ever tried). Creating a microflow to map these manually is a terrible solution but unfortunately the one we tend towards. Not only does it create clunky technical microflows but it also creates maintenance issues.

So what do we do make our lives simpler? Well fortunately the team from Mendix have provided the reflection module a perfect spot to get inspiration from. So using this starting point we construct a Java function to be called during the start-up microflows which using code inspired liberally from the reflection module runs through an enumeration set and populates an entity and voila we have a self-building entity to run our business logic and web service mappings off of.

Now words are great but let’s not recreate work for everyone and get to an example. So here we have a module (I will work on adding it to the store soon) EnumEntityBuilder with a simple entity FruitEnumEntity add it to a play project and link the FruitEnumEntity-Overview form from the navigation. I have provided 3 buttons to play with “Build”, “Clear” and “Find a fruit”. Build runs the Java function which populates the enumeration entity, the grid on the page will provide them. The second function clears the entities so knock yourself out adding new and removing new fruits. “Find a fruit” pops up a text search dialog to emulate a web service mapping to find that elusive enumeration.

Well I hope this can help you in future projects to save time and build more robust logic. And once more here is that example module: EnumEntityBuilder.mpk.