[Article] Managing graphics in modules (and other thoughts)

by David Workman
Data Mosaic

This tip is in response to a thread in the servoy forum regarding developing Servoy solutions using modules. In addition to Bob's best practice's tutorial on modules, there is a lot of good comments in this thread for things to watch out for and how other developers are doing things. Quite useful information.

Developing with modules is a great way to compartmentalize your solution so that multiple developers can work on the solution at the same time. This the major reason we started using modules. We soon found out that modules are also great for organizing a solution. By their very nature, if you don't have good naming conventions or a good design in mind for your solution then you will shortly be in a lot of trouble. The kind of trouble all of us FileMaker developers in a former life are famous for....

Additional module advantages I have found:

• the process of thinking through your solution to divide up into modules helps your design
• the unique naming constraints that modules enforce on you make you develop with a strict naming convention
• the ability to encapsulate specific functionalities and work flows into a module gives you a high degree of solution/code flexibility and reuse

All of the above can be accomplished without using modules but we all tend to be lazy or slip on occasion and name a form "spaghetti_land_101". Once this happens you are off the track and plummeting towards a land of no rewind. Put several developers on the same project and all of a sudden you have deal with a very scientifically researched formula:

big_f_ing_headache_for_dave = solutionSize x developerNumber x lazinessConstant x communicationFailureConstant x egoConstant x randomBrainFarts

If I haven't made myself clear so far: read up on modules, learn how to use them, and save yourself a world of hurt. Almost a requirement if your solution is of any major size and has multiple developers working on it.

Now we can get to the topic at hand. Managing graphics when you have lots of modules hasn't been addressed anywhere. Here's my <brain dump>. Enjoy.

Approach #1

Let's say you use 50 graphic files for your UI. Not out of the ordinary if you are doing something like this screen and have rollover images for all of your buttons:

Say I have this solution divided up into 10 modules and 5 of those have user interface screens. The most direct way to manage your graphics would be to put all 50 of your graphics in each module and call it a day. This is by far the easiest to manage as a developer.

The first downside of this approach is that your solution now has 250 (5 modules x 50 graphics files) files that have to be loaded by the client the first time. And this number grows for each module you add to your solution. 20 modules and all of a sudden you have a 15 minutes download. This doesn't make for a great first impression with a user.

Secondly, your solution is now a beast in size. Instead of a 400K file you could easily be exporting solution files 5G in size. Not so easy emailing those sumo babies around. Also, importing and exporting your whole solution takes a long time.

Summary: if you don't use a whole lot of graphics and/or don't have a high number of modules that use graphics -- this is the way to go. Because then you don't have to go through the pain of...

Approach #2

Let's talk for a moment about the modular structure used to build the screen shot above:

Each box represents a module or modules. The basic idea to come away from with this is that we use a "shell" module to combine all other modules -- business logic, utility, graphics, etc. Besides organizing everything, the shell module coordinates login/security and navigation for the business logic modules. Here is how the main screen of the shell module is constructed:

Sections (3), (4) and (5) are tabless tab panels. (3) has the navigation list. When you click on a navigation item, tab panels (4) and (5) are filled with forms from a business logic module. Since all form names in a solution have to be unique, this is simply a matter of specifying the form names in the navigation record and then loading them into the tab panels using the addTab('formName') function. Restricting access to certain forms then is simply a matter of not showing a navigation record unless a user has sufficient privileges. Quite elegant in terms of organizing a lot of modules.

There is a lot more I could say on this subject but let me get back to the subject at hand: dealing with graphics with all of these modules. As you can see, I have now put all of my graphics in one module (or more if we are using a purchased graphics kit -- this way we can individually lock the module with purchased graphics separately from other modules).

This graphics module is then included as a module in any other module that uses the graphics. In spite of this, when everything if combined into the final solution, only one instance of the graphics module is present. In a sense, Servoy "flattens" multiple instances of modules when everything gets put together. This is a good thing.

At this point, everything is great -- one graphics module for all other modules means I am only using one instance of a graphic throughout the entire solution. So if I have 20 modules and my graphics module has 50 graphics, the final solution only has 50 graphics. Good stuff eh? That is the theory -- now I just wished it worked exactly like this in practice!

A big note on making this system work: when you export a module that uses a graphics module, you MUST export the graphics module with the module in question. It would be really cool if you could just export the business logic module, import it into the shell module (which already has the graphics module included), and have the business logic module "see" the graphics module that is already in place.

Unfortunately, if you export a module that has references to graphics in another module and you don't include that other module -- all references are wiped out. If this one thing were fixed by Servoy, I wouldn't be writing such a lengthy treatise on this subject.

A major side affect (problem) to having to export the graphics module each and every time a parent module is exported is that you end up with a gazillion versions of your graphics module in the repository:

This is due to the fact that a new version is created every time a parent module is imported into the repository. If you have five parent modules that are getting exported/imported a lot they will all be on version 10 and the graphics module will be on version 50.

This is where the kicker happens: sometimes an ANOMALY occurs in the graphics module on import. I call it an ANOMALY because after hours of testing, we still haven't figured out the exact situations or reasons for the ANOMALY to happen. I can only tell you what the anomaly is: at some point you will notice that your graphics module contains multiple versions of the same graphic. This is the screen shot of the media window for version #53 of the graphics module:

As you can see, there aren't 53 versions of each graphic nor is each graphic duplicated the same number of times. This would be the definition of a Servoy ANOMALY in case you haven't followed anything else I've said so far in this article :)

This unfortunately gets us back to the problem experienced with method #1 of dealing with graphics: ending up with a solution with a ton of duplicated graphics. The result so far in our experience is not near as extreme as where we'd be by using method #1 but this particular solution is of 800K now and it is largely due to this graphics module.

The solution seems easy: go delete all but one of the duplicate graphics in the graphics module. Try that and you will spend the next three months reconnecting all of your graphics throughout your solution! It turns out that if you have an object in your solution that has a graphic property, Servoy associates the graphic reference by ID, not by the graphic name.

Somewhere in the process of importing/exporting modules, passing them among multiple developers and uploading to the main server -- graphics references start to multiply. It may look like the same graphic in name but the reference is to a duplicate version. The how and the why -- a huge mystery. There is one side effect that crops up as a result on occasion: one graphic will go missing. *Poof*. You'll do an export of a module you've been working on and import it to the main server and a random graphic will be missing on the server version. For lack of a better reason I think Servoy gets so confused it has to relieve stress by pissing the developer off in a minor but nagging way :)

If you are up for dealing with some of the weirdness associated with this method, it will result in a smaller solution size in the end. Not as small as you'd expect in theory unfortunately but certainly worth the effort.

Postscript

Troy and myself finally got pissed off enough over this issue that we sat down one afternoon and figured out the Servoy repository table relationships. As a result, we now have a bunch of SQL statements that you can apply directly to the servoy repository database that you can use to find all references to duplicate copies of a graphic and reset to connect to a single instance of the graphic. We'll gladly share this knowledge if someone wants. Or for a slight fee, we'll "flatten" out your graphics module and solution references for you. It's quite a detailed process -- not for the faint of heart.

</brain dump>. Hope this is helpful!