AnsweredAssumed Answered

managing large solutions

Question asked by RoelfWoldring on Feb 24, 2014
Latest reply on Feb 25, 2014 by RoelfWoldring

Title

managing large solutions

Post

     I am in a bit of confusion, and I am convinced that I am confusing myself.

     I am working on a very interactive app for a client.

     I am about 1/2 through and although the number of Tables and TOs is manageable,

     I am getting lost in the relationships between scripts, layouts and buttons.

     I have over 150 layouts now, and over 200 scripts. Because it is a very interactive application, may of the layouts contain button whichs trigger scripts which move to different layouts.

     Following all of this through is beginning to be painful, especially since FM does not seem to have a easy way to list all my buttons, tell me which scripts they trigger and which layouts they are on.

     I am struggling with naming conventions for all of this.

     I "use predecessor" codes (1st characters)  in my script names which tell me something about the nature of the script, stringing them together as required. I try to make sure that my script names tell me what they do, even though that leads to long script names.

          bbb = script fired by button 
          ccc = called by script script
          hhh = help screen script
          nlr = script no longer required 
               ppp = partial script 
          sas = start up app script
          sts = script trigger script
          ttt = script to be tested 
          www = script to be written
          uuu = script to be updated
           
          I try to keep my layouts organized in logical folders and the same for my scripts.
           
          But I keep getting lost on the buttons, which are the interactive glue between the layouts and the scripts.
           
          Does anyone have an insight into how they manage this problem?
           
          I seem be able to keep track of it all when the numbers are below about 100 to 125 each of layouts, scripts, and buttons, but after that, I seem to get more and more lost, especially as I try to take an agile approach to this development (code a little, test a lot, and then code some more).  Of course this is all aggravated by the fact that my client, when they see some functionality, immediately get new and better ideas about how they want to do things. I can push some of this into future releases, but not all.
           
          Although I have written a fair number of small to medium sized FM apps, this is really the first one that I would classify as on its way to becoming large.
           
          Roelf

      

Outcomes