There is a well-known German proverb that says, “There is more disputing about the shell than the application.” Well, that’s almost what it says, anyway! The point is, everyone knows what an application is (if you are now feeling embarrassed because you don’t, read my previous blog post, “Applications and adapters”). But there is a lot of mystique surrounding the term shell in Worklight. Here is the kernel of what a shell is.
Often, many people (or several teams) will be involved in developing an application. There may even be a series of applications that are related but are being developed by different groups. An application requires several different constructs or configurations, and each team must provide the code for these artifacts. Thus, for example, teams may provide this code for their final product:
There are two potential problems here. First, each team needs to be aware of all corporate policies concerning security and so on, and needs to have checks in place to verify the correct implementation. Second, each team must duplicate this effort, because each application will require the same framework. The problems can therefore be summed up as follows: teams may not have the expertise to implement the structure correctly, and any modification to the structure involves recoding each application.
The solution is not new, and examples can be found in many programming environments. This is a governance issue that can be resolved by imposing a top-level structure that will be used by all teams. The structure must be flexible to allow for the different needs of each application, and it must be comprehensive to cover all common requirements of the applications. The example that springs to mind from past experience is the interface in Java, which imposes an imperative structure on any application that uses it. The Worklight shell has many parallels to the Java interface, and this will be clearly defined in the next section.
An empty shell
The Worklight shell is created through a wizard. Interestingly, and correctly, the shell is not called an application; it is called a component. This is correct because the shell is not in itself executable (this is one parallel between the shell and the Java interface). Here is the framework that is generated.
You can see that the shell component has much the same structure as an application. The two new elements are the fragments folder and the preview folder. Fragments holds read-only parts for the main HTML page. These can be used to display immutable information (“contact us,” the company logo, and so on), or to enforce the inclusion of scripts or links. Again, you can see the parallel with a Java interface. The preview folder may contain stub code to simulate functionality that has not yet been implemented.
An application is automatically added to the apps folder as a way for the shell developer to test the code. You can see in the screen capture above that the test application is given the name of the shell plus the word test.
When the shell is ready, the developer builds a component, a single file that bundles together all the bits and pieces of the shell environment. This shell bundle is a wrapper for an application, and since the application lives inside the shell, it is called an inner application. You cannot create an inner application unless you first obtain a shell bundle.
So what goes into an inner application? That will be the topic of another blog! Let me know what you think. I’m sure you will be impatient to write shells now!
After all, as they say in Lichtenstein, “wenn du musst diesen Text im Internet übersetzen, offensichtlich sprichst du nicht deutsch.” Yup. That sums it up.