A Framework for Easily Managing UcompOS Applications

As I’ve worked with the UcompOS platform since its Public Alpha release, I have come to be impressed with its flexibility in bringing a lot of different applications together into one portal system.  However, as I built and tested various applications, it became very apparent that I needed to take a few steps back and think about a framework for deploying applications or risk becoming engaged in a never-ending battle with the following tasks:

  • Editing static dock manifest files
  • Keeping application manifest files between applications straight
  • As the number of applications increases, easily finding the files I need to change without worrying about breaking another application becomes a challenge
  • Deploying updated versions of the UcompOS runtime without accidentally deleting or overwriting application content
  • Managing permissions to applications for different users

These issues were tackled in a fairly systematic manner.  My first logical step was to get rid of the static dock manifest and move that to some application code that generates the dock manifest from a database.  For my UcompOS implementation, information for applications that go on the dock menu is pulled from a very simple table that looks like this:

database_table

The Application_ID field is just a numerical value indicating the identifier of the application.  It is the primary key for the database and auto increments as new applications are installed.  The Application_Descriptor field is very simple, in function to the “title” attribute in your application manifest.  The Background and Default_State fields contain the values each application should have when they are added to the dock manifest file dynamically.  The Directory_Path field requires a bit of explanation.  What I’ve done is create a folder called “applications” in my UcompOS implementation where all applications reside:

project

The Directory_Path field is the name of the folder where each of my UcompOS applications is launched from.  The final field, Is_Global, is a field that indicates whether or not the application should be globally accessible to all users of my UcompOS Portal or not.  Note that if this field is set to false, I have another database table that contains the list of users who have access to the application.

This database is managed through a front-end that grants/denies access to applications based on the selection of a checkbox (Checking a box calls an AJAX function that automatically adds/removes permissions to various applications) like in the screenshot below:

roles

With all this in mind, the script that generates the UcompOS dock manifest file performs the following actions:

  1. Add all of the global applications in my applications table to the dock manifest
  2. Retrieve the list of which applications the user has access to, and add those applications to the dock manifest
  3. Return the entire dock manifest file to the UcompOS main container

You will notice above that I did not provide a filename for each application’s manifest file (just a directory path).  This was an intentional decision, as I chose to have a convention where the name of the application manifest file would be in a sub-folder called “manifest” under each application’s folder, and that the application manifest filename would be the same for each application.  This makes it very easy for me to easily identify the application manifest for each application, and helps maintain consistency across my UcompOS applications.

manifest

In my case, this application manifest for each of my UcompOS applications is named “getAppManifest.php”, and it is a simple script that returns the XML application manifest for the application.  In it, the file does a security check to make sure that the user is logged in and that they have permission to access the application (if the application isn’t global).  If everything checks out, then gatAppManifest.php spits out the application manifest for the application.

I should note that, for very practical reasons, I chose not to place the information for each application manifest file into a database table.  While this was certainly a consideration, the realization I came to was that this was going to be just too cumbersome, especially if you factor in the possibility of multiple languages.  Also, I considered the fact that this file is fairly static in nature, and wouldn’t need to be managed all that often.  Ultimately, I felt that there wasn’t going to be much of a difference time-wise between managing this manually or through a database interface.  For my framework that stresses ease of use, managing the application manifest via straight XML presented a far more straightforward path.

Before I close, I wanted to briefly touch on the file structure I have in place for my implementation.  By having each application compartmentalized in its own subfolder, it is much easier to troubleshoot and find issues with each application without worrying about breaking anything else.  Further, it allows me to do a simple drag and drop operation to deploy new applications in my UcompOS framework (I have a simple function in my application manifest file that adds the new application to the Application database if it doesn’t exist, and sets up any auxiliary tables needed for the application.  I also have been able to create several reusable templates I can leverage or when I begin work on a new UcompOS application).  Ultimately, the framework I’ve put into place solves all of the issues I mentioned above and greatly simplifies the application deployment  process, allowing me to focus on application functionality instead of the mechanics of application deployment, which for me, is what it’s all about.

About Tom Petz

Comments are closed.