Better Code Organization for Infor CRM (Saleslogix) Mobile Customizations

When customizing the Infor CRM (Saleslogix) Mobile client, it’s common for the ApplicationModule to grow very large as more and more customizations get added into it. This makes the code difficult to work with and very poorly organized. There are some better solutions to keep your code nicely organized and easy to maintain.

View the SalesLogix Mobile Developer series index

Application Modules

First of all, an ApplicationModule is a customization file that mixes in, or inherits, a base ApplicationModule class, allowing you to customize various parts of the mobile client without touching the actual files that make up those parts. See more about this topic on my previous post Adding Custom Fields to SalesLogix Mobile. For example, if you’re adding and removing fields on the ticket detail, edit, and list views, you’ll create an ApplicationModule to register the customizations on those views. If you’re using the SalesLogix Mobile Developer Toolkit, the creation of this ApplicationModule is the quick click of a button. Although it is common for the ApplicationModule to be named ApplicationModule.js, there’s no requirement that it is named that. If I wanted, I could create several ApplicationModule’s all within the same customization application (a customization application is your “argos-whatever” subfolder under the products folder). I could have a TicketApplicationModule.js, AccountApplicationModule.js, OpportunityApplicationModule.js, etc, and then add them all to the application development and production configuration files so they are all loaded into the customization application. While, that is much nicer than having all the ticket, account, and opportunity customizations all thrown into a single, huge, & messy ApplicationModule, it still can be too much code to have all together for my tastes. For example, If my ticket Edit view has a lot of customizations, I like that to be separate. Especially if the ticket Detail, List, etc also have a lot of customizations. It’s just too much code in the same file for me. It makes it harder to find things, harder to see what you’re working with. A common pattern to solve this is to create several functions, one for each view or area you’re customizing. You can see an example of this in the official sample customization application, argos-sample. There’s one ApplicationModule.js file with almost 600 lines of code. Each view that is being customized or extended has a separate function that contains the customizations for that view, registerAccountCustomizations, registerContactCustomizations, registerOpportunityCustomizations, and so on. That approach isn’t necessarily bad, it’s just too much code in a single file, not to mention there’s no separation of concerns. For me, I like to have things nicely organized, with code for each separate purpose being in a separate file.

Separating Code by View

If you’re adding new views to your customization application, then you already are likely following the same folder structure as in argos-saleslogix. That is, you’re creating a “Views” subfolder in your customization application with a subfolder for each entity under that. So, if you’re creating views for an AccountProject entity, you’ll likely have a folder named “Views/AccountProject” that contain files like Detail.js, Edit.js, List.js, etc. I like to follow this same pattern with customizations. If I am customizing the ticket Detail, Edit, & List view, I like those customizations to be in a “Customizations/Ticket” subfolder and be named after the view they are customizing, such as Detail.js, Edit.js, and List.js. Then your ApplicationModiule.js is just the entry point to your customization application and all the code is nicely separated based on what it is for. To do this, I usually do the following. For example, if I am customizing the ticket Detail view, and changing the “Subject” field’s label to “Topic”. I’ll create a “Customizations/Ticket” subfolder in my customization application, then create a Detail.js file and add the following code:

define('Mobile/CustomApp/Customizations/Ticket/Detail', [
    'dojo/_base/lang'
], function (
    lang
) {
    return lang.setObject('Mobile.CustomApp.Customizations.Ticket.Detail', {
        registerCustomizations: function() {
            this.registerCustomization('detail', 'ticket_detail', {
                at: function(row) { return row.name == 'Subject'; },
                type: 'modify',
                value: {
                    label: 'Topic'
                }
            });
        }
    });
});

That’s a really simple example, but if I had a lot of customizations and things to extend onto the ticket Detail view, it would be nice to have those all separate. We’re using Dojo’s setObject to set our object containing our registerCustomizations function (which contains all the customization code), to the name “Mobile.CustomApp.Customizations.Ticket.Detail”. As an aside, this is a nice way to separate utility code as well. Now, I need to add this to the main ApplicationModule.js so it gets loaded. In the ApplicationModule.js, you’ll add the following:

define('Mobile/CustomApp/ApplicationModule', [
    'dojo/_base/declare',
    'Mobile/CustomApp/Customizations/Ticket/Detail'
], function (
    declare,
    ticketDetail
) {
    return declare('Mobile.CustomApp.ApplicationModule', Sage.Platform.Mobile.ApplicationModule, {

        loadCustomizations: function () {
            this.inherited(arguments);

            ticketDetail.registerCustomizations.apply(this);
        }

    });
});

What we’re doing there is adding our new customization object as an AMD module, calling it ticketDetail, then where you would normally find the customizations in the loadCustomizations function, we’re instead calling the registerCustomizations from our separate object. An important thing to note, is the use of apply so we can set context to “this” in our customization object. In the ApplicationModule.js, we’ve mixed in the base ApplicationModule. This is what gives us things like the “registerCustomization”, “registerView” that you’re using. We can pass along that stuff to the customization class by setting the “this” context to our ApplicationModule. Then it will also have things like registerCustomization available to it. Also, another nice benefit of doing it this way, if you wanted to define shared functions in the ApplicationModule, you’d get that passed along too in the “this” context. Here’s a screenshot of the folder structure of a mobile project I just finished using this same code organization:

This is a smaller project and it saved my sanity. For larger projects, the benefits become more and more apparent.

Deployment

I should also mention, that if you’re separating your code into files like this, don’t forget you need to add each file to the release.jsb2 file when you add everything to Application Architect. The release.jsb2 file is what tells which files to combine into a single argos-customapp.js file. If a file isn’t listed, it won’t be added.

Conclusion

This way to organize your code might not be for everyone. For me even, it’s still a work in progress. All I know is that if I have to work with another ApplicationModule that has code for tickets, opportunities, and everything else all thrown together into a single, huge file, I might go postal. For the time being, this way keeps me, and my OCD, happy.

View the SalesLogix Mobile Developer series index

ABOUT THE AUTHOR

Ryan Farley

Ryan Farley is the Director of Development for Customer FX and creator of slxdeveloper.com. He's been blogging regularly about SalesLogix since 2001 and believes in sharing with the community. He loves C#, Javascript, Python, web development, open source, and Linux. He also loves his hobby as an amateur filmmaker.

Submit a Comment

Your email address will not be published. Required fields are marked *

Subscribe To Our Newsletter

Join our mailing list to receive the latest Infor CRM (Saleslogix) news and product updates!

You have Successfully Subscribed!