I’ve been doing apex for about 7 years now, and along the way I discovered a few things that made my life as a developer a lot easier. I made a list of 5 things thar I wish I had known wen I just started. Those things will be explained to you in a series of 5 posts.

Subscriptions

One of the most tiresome things to do when managing multiple applications is to keep things like templates, and security up-to-date across all applications.

Apex has a nice built-in system for this called ‘subscriptions’.

If you just start with a new project, the easiest way to set-up the subscriptions is by creating a new application and call it “MASTER APPLICATION” or something similar, so you know this will be the parent application for all subscriptions. For an existing application the same method applies, but it will be a bit more work intensive to get everything right.

Once you have your basic configuration done, you are ready to start working on your new applications.

To link the new application to the MASTER application let’s say for example an authorization scheme.

You go to shared components, authorization schemes, create.

Select “create as copy”.

Copy from the master application and then select copy and subscribe.

If you edit the authorization scheme now you will see that in the subscription part there is an application referenced.

By now you are wondering: “What’s the point of all this? Couldn’t I just as easily have copy pasted the code?”

Yes, you could have, but imagine having 20 or more applications using the same authorization scheme, and then one day you may have to change something inside, you would have to modify all 20 schemes in all 20 applications again.

But because now we reference the master template this is no longer necessary. For instance let’s say we want a function to return false instead of true, what we can do now is go to the master application, edit the authorization scheme, change it, save it, and press the publish scheme button.

In the long run this could save you tons of work!

For subscribing templates in apex there is a way to do all templates at the same time.

Go to shared components, templates.

On the righthand side you have a menu called task, click the link to replace templates in this application with templates from another application.

Select the master application again, in the next screen select the template, and in the action drop down select, replace/subscribe, and press replace templates.

In the previous blogpost we discussed a way to reduce the amount of global variables by using namespaces. Today, we will be looking into a different way to hide functions and variables.

If you write JavaScript code on a regular basis (without being an expert) you might have heard about ‘closures’. While closures are becoming increasingly popular in other programming languages as well, JavaScript allows you to take them one step further.

Sometimes you want to run a block of code, define properties, etc without having to worry about the global object (5 MIN JS #4). If this is the case you could use a closure function to which you can bind your variables.

This is a function that is executed immediately. This means that the code result might be the same, but in the second example the ‘bound’ variable isn’t added to the global object. The difference between the ‘free’ and ‘bound’ variable is that the ‘bound’ variable is cleaned up after the function execution ends. This happens because its context is finished executing and it isn’t bound to a higher scope (such as the global object).

Some frameworks help you in writing better code without you knowing it. For example in jQuery, you are advised to use the $(document).ready(function() { }); function. Thanks to jQuery the programmer is actually using a closure, he’s defining a function that is passed along as parameter to the ready function. But this also means that all the variables defined while initializing are also set to ‘non-global’.

Last post we noticed that variables can easily be attached to the global scope. This isn’t a good thing. The more variables are linked to the global scope the more chance you have creating conflicts.

A great way to reduce the impact of your code on the global object is to define namespaces. We do this by creating one global object that we extend with extra modules which on their turn can be extended with new functionality and properties.

By defining the Application namespace (and the two module ‘packages’) we have no conflict between the two difference calculate functions. We also know at all times what function we are calling from which subproject or module.

This is a first step into creating frameworks, but it’s not the best solution. Most daily JavaScript users know this pattern and are using it to reduce conflicts. However, we know that in JavaScript functions are very important, so maybe we are able to improve this solution by throwing in some functions?

On March 27, 2014, the Spring community was happy to announce the Spring Framework 4.0.3. The reason why is that it was the first release of the Spring Framework with Java 8 support. Since then, the Spring team worked very hard to provide major updates for the Spring Framework to be even more supportive towards Java 8. As of September 4, 2014, the Spring Framework 4.1 has arrived with even more support towards the Java community.

Lambda support in Spring 4.0

A good example to show the Lambda support in Spring is the JdbcTemplate class. If we would like to obtain female employees and map them as an instance of type Employee, we could do something like this:

As of Spring 4.1, JDK 1.8’s java.util.Optional is now supported for @RequestParam, @RequestHeader, and @MatrixVariable controller method arguments. This means that while using Java’s Optional, you make sure that parameters are never null.

The following example shows an example of a @RequestParam in Spring MVC prior to version 4.1.

JavaScript uses the var-statement to declare variables and bind them to a scope. But this statement isn’t mandatory. In JavaScript you are allowed to define a value without this statement. When you do not use the var-statement, the variable will be added to the Global Object (see previous post).

function f () {
x = 1;
}

Whenever we execute f we won’t bind the x variable to f, instead we will define a new property named x on the global object. So, it definitely seems like a good plan to always use the var statement! But sometimes you can just forget to define the value before using it…

If in this example you had forgotten to declare x before using it (in the if-statement), you would have declared x globally. Since these kinds of issues are hard to detect, you will need to be disciplined in your variable declaration because JavaScript won’t force you to do it.

When you define x without any value, you are actually saying “in this scope there is a variable with name x, but its value is undefined”. The next time you will attach a value to the variable you won’t need to use the var-statement.

Now that we know how to create scopes and how to bind variables to them, we should also be aware of JavaScript’s global object. Whenever we declare a variable with the var-statement, the variable will be bound to the nearest scope. But what happens when there is no scope? It needs to be attached to something, right?

<code>
var x = 1;
<code>

In this example, there is no function to which x can be bound. Therefore x gets added to the global object. Being part of the global object means that the value is accessible from everywhere. This might sound exciting, but you have to know that this can cause a lot of problems. A filthy global object is a ticking time bomb, waiting to explode and become conflict issues.

Some JavaScript create multiple script files containing functions and include them in their HTML-page based on some back-end logic.

script-module1.js

function calculate(){}
function redirectTo(){}

script-module2.js

function calculate(){}
function doSomething(){}

Imagine these files to be part of two different modules, designed by two different teams and combined into one application. If these two files get included into one HTML-file, a conflict rises for the calculate function and unexpected behaviour is possible. This is because functions are also values and we know that values that aren’t bound to a scope are part of the global object.

So although these functions are in different files, they can be combined into one HTML-page and that’s when conflict issues tend to rise. These conflicts are sometimes very hard to find (especially in large code bases).

If you want to know what’s defined in the global object, you can always check the window object (only in browsers, NodeJS works differently). This object contains all native JavaScript functions and all the functions/variables you have defined globally.