Building off of our previous blog entry regarding the developer center, application management and distribution has been fleshed out to a point where we are ready to reveal the changes coming with the 4.0 Social Suite. Please keep in mind that while we are discussing some specific changes (and showing screenshots!) of changes you can expect to see in 4.0, everything in this blog entry is subject to change before final. With that said, let's take a look.
This screen represents the application overview screen. First, a list of all of the applications that are currently installed is presented to you in a table, with another table following this one listing the applications which are uploaded but not currently installed. You can easily install an application listed in this second table on the screen simply by clicking the install icon next to the application. A multi-redirect process is triggered which handles the application installation painlessly for the administrator.
Note that in the screenshot above, the "Create New" button is only presented because developer mode is enabled. Administrators will not normally see this button. Additionally, the gears icon next to the installed application allows you to access the developer center, and this button is only present when developer mode is enabled as well.
When clicking on an installed application, you will be presented with a list of front-end modules, allowing you to set permissions for those modules and to specify which module is the default for that application, and to enable or disable individual modules.
The lit up star icon indicates the default module - clicking the icon for any of the modules will specify that module as the default. Clicking the lock icon will allow you to specify the permissions for that module, and clicking on "Enabled" in the screenshot will toggle the module between enabled and disabled status.
Building and Distributing Applications
Beginning with the 4.0 Social Suite, building and distributing applications has been made as simple as possible. The concept of "building" an application refers to the process necessary to create all of the files distributed with the application in order to make it installable. Examples include the language strings and the skin templates associated with the application. While you work in developer mode, the software pulls these templates from files located on disk, however these skin templates and language strings need to be imported into the database for standard installations of the suite in order to be supported properly. In 3.x the way you do this is to visit each various area of the ACP and use the appropriate developer tools to first import the data, and then to export the data. This is no longer necessary with 4.0.
In 4.0 when you add most database-stored data, you do so through the developer center. This immediately puts the relevant data (such as a task or settings included with the application) into the database, as well as into the distributed files on the file system. You don't have to be concerned with building this type of data for application distribution.
Within the developer center there is a manual "Build for release" button which you can use at any time. However, most developers will likely find that they do not need to use this button, because you are given the option to build your application for release right when you go to download it. This brings us to application distribution.
In 3.x to distribute an application, after you have exported all of the various files you need to distribute to disk you would copy over the application folder, as well as any other files from other folders (e.g. javascript files in /public/js/) and then zip these folders up in order to create an application distribution you upload to the marketplace. 4.x does away with this entire process. Firstly, applications are now fully self-contained within their own directory, including javascript files, images, CSS files, skin templates, language files, and so forth. Applications no longer need to have files contained within half a dozen folders to be recognized by the suite.
Secondly, you can now directly download an application (with developer mode enabled) right from the ACP. Behind the scenes, the PharData class is utilized to build a .tar archive, and all of your application's files are pushed into this archive. You are given the opportunity when you elect to download your application to choose whether you wish to build the application or not, which is useful in case you have just made a minor bug fix and don't need to bother with importing skin templates or language files since the last time you distributed your application.
Installing Applications
We wouldn't be content with just making application distribution this simple when we can make application installation just as simple for the end user administrators. As of 4.x, while you can still extract the .tar archive you (as a developer) have distributed and manually upload the files, it is much easier to simply upload the entire application in the ACP and let the 4.0 Social Suite do it for you. When you click the "Install" button on the application overview page and select an application to install, the archive is uploaded and extracted, and then the same install process automatically executes that happens if you are installing files from disk.
Centralized "Offline" Mode
Most nodes within the software have a notion of enabled or disabled, and applications are no exception. Even in 3.x you can enable and disable applications without uninstalling them, which removes access to the application within the software. On top of this, however, almost all applications have a custom notion of "offline mode" where-by an administrator can put the application in offline mode, define a custom message to show users who attempt to visit the application, and in most cases also specify which groups can still access the application even while it is offline.
We have decided to consolidate and centralize this similar functionality, allowing for a more consistent and robust experience for the administrator. You can now put applications in offline mode (unless they are "locked", such as the system application) and specify a message to show to users and which groups can still access the application. This functionality replaces the basic enabled/disabled status, but still provides for the same end functionality.
Putting it all together
Here is a quick video showing the process of installing an application, specifying a default module and the permissions for that module, and putting the application into an offline mode.
You might notice a few quirks in the video, representative of pre-alpha software. Firstly, this is an early application export and the module title was not exported with it, so the key is displayed when you see the listing. Additionally, a full WYSIWYG editor will be presented in the popup to specify the offline message, however automatic javascript-dependency loading is something we are still working on. Nevertheless, you can see the full functionality in the video below.
http://screencast.com/t/2zK1L51Tp3I
Let us know your thoughts, and if there are any other application-management tasks that need some extra attention in 4.0, in the comments