From: ibisnestremovespambit@iinet.net.au   
      
   Juri,   
      
   Thanks for this - see comments inline @@@   
      
   BTW - I appreciate this thread as a chance to see how others put   
   applications together - which is what "architecture" means...   
      
   modri dirkac wrote:   
   >> My app has 420 forms, 55 scripts and 34 libraries   
   >>   
   >> The reason I asked was that a ratio of almost one library per form (335   
   >> libraries versus 540 forms) suggested you were holding most code in   
   >> libraries and not sharing it between forms - hence maybe not getting   
   >> maximum benefit of libraries...   
   >>   
   >> Do you have a particular way of handling code that requires lots of   
   >> libraries?   
   >   
   > On forms I do not have almost any code. Only necessary code   
   > for data-entry (show lookup form, create new document)..   
   > Everything else is done in libraries: when you enter ID code, I call library   
   > to   
   > get its price, I check library to get qty on stock, when you confirm a   
   > document (for example order or invoice),   
   > I call library with only ID of that document.   
   > Usually, for data entry I have les than one library per form.   
   > Some other libraries are for general analytics in certain module, some are   
   > for cross module comunication,   
   > but most of them are for preparing data for reports.   
      
   @@@   
      
   Understood - makes sense to have as much code as possible in small   
   number of locations to allow ease of managing business rules about data   
   entry.   
      
   @@@   
   >   
   > I have a system with INI files where I can add new analisys methods and   
   > reports:   
   > *each form knows from which INI file to read,   
   > *in INI file I have a group where I list all reports, that are available on   
   > that form:   
   > [Reports]   
   > Form name=report1,report2,report3,analytics1,analytics2,...   
   > This options are shown on form in popup menu, when I press right mouse on   
   > printer button.   
   > I can also set default report for left mouse button.   
   > So different forms can easily share same reports.   
   > *when user selects a report, I read from INI file, what to do with that   
   > choice:   
   > [Reports]   
   > Report1=Report,:BMW:rep1,Landscape,1   
   > ; just show a rsl file   
   > Report2=Library,:ALIAS:lib,SOME METHOD,:ALIAS:report   
   > ; open library ":ALIAS:lib" and executemethod "SOME METHOD", which will   
   > crete answer.db, then show report.   
   > Report3=Library,:ALIAS:lib,SOME OTHER   
   > METHOD,:ALIAS:report,Landscape,3,Printer   
   > ; same as above, only that report is landscape and is printed automaticly in   
   > 3 copyes.   
   >   
   @@@   
      
   I have a report table which holds all reports, the methods used to drive   
   them, and other controls like format and size. Some reports are big   
   enough to require a plotter and A2 paper. Then I have a form where I can   
   present the list of reports, complete with information about what they   
   are for, classified in various ways - for example, Finance, Assets, Work   
   Management and so on.   
      
   I understand the idea of the INI files - but always prefer to use tables   
   for lists if possible...   
      
   @@@   
   > ALL my libraries have common entry point, which excepts only "method name"   
   > and var DynArray for parameters.   
   > ALL my forms have common exit point for calling other objects. In DA they   
   > store data "who is calling" and   
   > document ID, I am currenty standing on. That is all I need to do anything   
   > with that document:   
   > create a report, copy it, change status, change some data, check for   
   > stock,...   
   > So I can create new reports for customers whithiut changing any forms   
   > (application).   
   > Just create new library (on separate alias), add choice to INI file and   
   > create new rsl.   
   > That is why I have so many libraries, but their average size is 30 kB.   
   >   
   @@@   
      
   You have about 500 customers (I wish!) but how do you handle the   
   multiplicity of customers and reports and libraries?   
      
   Why not just add a method to a report library (I have 3, for about 250   
   reports, some of which are really just slight rehashes of some basic   
   report - same data, different layout)?   
      
   On the other hand, the methods do not share much in common, so the main   
   issue is knowing which library to call.   
      
   How do you keep track of which customers have which reports / libraries?   
      
   @@@@   
      
   > There are also some 20 libraries for commmon use, which handle certain   
   > actions:   
   > creating PDFs with different programs, ZIP/unzip, handle INI files,   
   > translate my installation language scripts,   
   > create generic lookup forms, ...   
   >   
   > I got over size limit for library only in two cases and had to break it up   
   > to more libraryes.   
   > I did it in that way, that I still call "maain" library for all methods, but   
   > for some methods   
   > in "main" library I just call second library:   
   > mainlib.lsl:   
   > method someMethod(var da dynrecord) smallint   
   >     return(mainlib2.someMethod(da))   
   > endMethod   
   > So application does not even know, I split up that library.   
   >   
   > When I have to call methods in other objects (forms, libs), I explicitly   
   > define ALL   
   > methods in USES of that library, NEVER use that short form "uses ObjectPAL   
   > lib.lsl endUses".   
   >   
   @@@   
      
   I found using the long form was a pain, in that if you change the   
   parameters for a method, you have to chase down all the objects that use   
   the method. Have you found some problem with the short form?   
      
   @@@   
      
   > And now some things I am very proud of:   
   > *XML generator I described in some other group,   
   > *"excel like" parser/calculator with nested ((()())()), iif structure, GOTO   
   > command, and calls to functions.   
   > *common method in stock inventory, which accepts only name of answer table   
   > to fill,   
   >  and then decides (by field name) how to fill appropriate columns. (create   
   > one giant query with multiple tables,   
   >  links and conditions and also calc structure).   
   >   
   > Jure   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)