Import and Export Project Resources to Save Time
Import and Export Project Resources to Save Time by Eric Tieniber
Whatever you are trying to do, someone has probably done it before. Often times, they’ve even done it better than you would have. This is definitely not a new concept – and there are many cliché quotes that come to mind:
Don’t re-invent the wheel, realign it!
Stand on the shoulders of giants.
Reduce, Reuse, Recycle!
I recently completed a How-To article on importing and exporting resources within a Mendix project. In summary, you can quickly and easily export a page, Microflow, module, or even an entire project to a Mendix Package (.mpk) file. Then, you can import that package file back into another project.
I’ve used this functionality in a number of ways:
- Sharing projects outside of the Team Server
- Sharing modules between projects
- Storing and removing unused objects in a project, but keeping them for retrieval later
- Adding widgets and modules to your project that are not (yet) in the App Store (and here’s how to add content from the App Store to your project)
Sharing Projects Outside of the Team Server
In any application, occasionally you will run into a bug or issue that you just cannot resolve yourself, and you will need some outside assistance. In these instances, you need a way to share the problem so that the right people can reproduce your issue and suggest a solution. Whether to submit a support ticket, share within a forum, or discuss within the project group, you always need to include a demo project.
I use the export project functionality constantly for this purpose. You could certainly do the same any time you need someone outside of your project to review as well.
Sharing Modules between Projects
There’s not much sense in rebuilding something that already exists. So, if you come across a situation where you can re-use a piece of an existing project in your new project, make every effort to do so. Not only is much of the development probably already done, but you’ll also minimize hidden time-sucks like testing and bug-fixing. This will ultimately save you time, effort, and headaches, not to mention surprise your business users.
Storing and Removing Unused Objects
Keeping unused pages, Microflows, and modules just because you might need them later will slow down your build times, and ultimately make your application bloated and difficult to navigate. Even though your project may not need the unused pages and objects, they still need to be compiled – and that means it will take longer to run the application in the Business Modeler.
Instead, export those unused pages and Microflows into a Mendix Package file, and put them away for safe keeping. You’ll satiate the hoarder inside of you without affecting your build speeds and project size!
Adding Widgets and Modules Not In the App Store
First, check out the GitHub repository for that module or widget (usually there’s a link right from the App Store). Many times, unofficial builds of these objects will be available on GitHub before they are officially published to the App Store. These builds can often get you past a nagging bug. Beware, however, that these objects might have bugs of their own, and haven’t been officially approved for the App Store. Make sure you test, test, test!
If you don’t see a widget or module in the App Store, I highly recommend searching the forum and then asking a question about your use case. Instead of spending all the time and effort to build something yourself, ask the community what they’ve done or built to achieve particular functionality, and build off of that.
Case in point:
A few weeks ago in the office, one of my colleagues (Chad Evans) was trying to call a web service using NTLM authentication. (For those unfamiliar with NTLM, it involves a whacky authentication process when paired with SOAP, and Mendix doesn’t natively support it.)
After playing with custom SOAP headers directly in the Business Modeler, he decided this was a job for Java. He still wanted to use the built-in Mendix XML conversion tasks, and simply use Java to handle the authentication and web service calls.
Last week, a community member posted a question on the forums about connecting to an NTML-authenticated SOAP service. I saw the question, mentioned it to Chad, and he had just committed his NTLM module to GitHub. We passed that information along in the forums, and voila, our community member has a functioning web service call in his project!
In each instance, I’ve saved myself considerable time and effort, all of which I can use to focus on solving the business problem at hand. In the end, it’s all about amazing the end users. And delivering on or ahead of schedule is a great way to keep them engaged and show that you’re committed to the project and to solving their business problem.