[BR_forum] Organizing Libraries

Discussion about Business Rules! functions and library facilities.

Moderators: Susan Smith, admin, Gabriel

Post Reply
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

[BR_forum] Organizing Libraries

Post by Susan Smith »

MORE libraries or FEWER LIBRARIES?

I'm trying to reorganize my libraries because they are a mess. I'd love to find out how most of you set up your libraries. Do you use one library for screen routines and one for printing? Or possibly one general purpose library and one which is specific to different clients? I tried to do all of the above and now I can't seem to keep consistent libraries that make sense. There is a lot of overlap. I'd love the benefit of your experience.

I thought that it would make sense to have MORE libraries that were specifically tailored to narrower topics, but now I'm not sure. As many of you know, I don't have a vertical application. Each of my clients have a custom system. They COULD share some library code though, which is the point of course! But some routines will always be specific to one client. Should I just put everything in one library, including the client-specific stuff in case it might someday be used by a second client after all? Mix screen IO and printing? What to do with data-related routines? Thoughts? How do YOU determine how to structure your libraries?

-- Susan
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] Organizing Libraries

Post by John »

i'd seperate things by objective like

print.wb
screen.wb
accounting.wb
payroll.wb
array.wb

etc,,,  this helps make things easy to find and obvious where they belong...   or you might consider one big redirect library that points to everything.  and then each library have it's own .wb file.  this is great for limiting scope... but if you want your libraries to behave more like objects and share variables, than you can include just those libraries in a single .wb file.

i've worked all three of these ways with great success...  I think I like the first one the best... even if the libraries aren't sharing variables, it's most convient for me to have all my printing related libraries in one single print.wb, and it not be mucked up with array libraries or application specific processing (like payroll.wb)

2 cents,
-john

On Sun, May 10, 2009 at 10:54 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
MORE libraries or FEWER LIBRARIES?

I'm trying to reorganize my libraries because they are a mess. I'd love to find out how most of you set up your libraries. Do you use one library for screen routines and one for printing? Or possibly one general purpose library and one which is specific to different clients? I tried to do all of the above and now I can't seem to keep consistent libraries that make sense. There is a lot of overlap. I'd love the benefit of your experience.

I thought that it would make sense to have MORE libraries that were specifically tailored to narrower topics, but now I'm not sure. As many of you know, I don't have a vertical application. Each of my clients have a custom system. They COULD share some library code though, which is the point of course! But some routines will always be specific to one client. Should I just put everything in one library, including the client-specific stuff in case it might someday be used by a second client after all? Mix screen IO and printing? What to do with data-related routines? Thoughts? How do YOU determine how to structure your libraries?

-- Susan


_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
John Bowman
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

[BR_forum] Organizing Libraries

Post by Susan Smith »

Thanks. I like the first idea as well. I already have my printing library pretty much cleaned up, so I'm part way down the road for that one. Maybe for any client-specific things, I'll just put the functions inside the appropriate general library (screen, print, acctspay, etc) and not worry about what client they are for. I can self-document those functions as to what client uses them and that way I can continue to use the same libraries across all clients. ("continue" is wishful thinking as I am not doing this now, which caused all of the problems with overlapping librarys in the first place!)

-- Susan

John Bowman wrote:
i'd seperate things by objective like

print.wb
screen.wb
accounting.wb
payroll.wb
array.wb

etc,,, this helps make things easy to find and obvious where they belong... or you might consider one big redirect library that points to everything. and then each library have it's own .wb file. this is great for limiting scope... but if you want your libraries to behave more like objects and share variables, than you can include just those libraries in a single .wb file.

i've worked all three of these ways with great success... I think I like the first one the best... even if the libraries aren't sharing variables, it's most convient for me to have all my printing related libraries in one single print.wb, and it not be mucked up with array libraries or application specific processing (like payroll.wb)

2 cents,
-john

On Sun, May 10, 2009 at 10:54 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
MORE libraries or FEWER LIBRARIES?

I'm trying to reorganize my libraries because they are a mess. I'd love to find out how most of you set up your libraries. Do you use one library for screen routines and one for printing? Or possibly one general purpose library and one which is specific to different clients? I tried to do all of the above and now I can't seem to keep consistent libraries that make sense. There is a lot of overlap. I'd love the benefit of your experience.

I thought that it would make sense to have MORE libraries that were specifically tailored to narrower topics, but now I'm not sure. As many of you know, I don't have a vertical application. Each of my clients have a custom system. They COULD share some library code though, which is the point of course! But some routines will always be specific to one client. Should I just put everything in one library, including the client-specific stuff in case it might someday be used by a second client after all? Mix screen IO and printing? What to do with data-related routines? Thoughts? How do YOU determine how to structure your libraries?

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

[BR_forum] Organizing Libraries

Post by Gabriel »

I think you're on the right track with this now.
 
I often also have specific libraries for any data files that need more complicated logic associated with them. In my SageLive system I have an Invclib with functions specific to adding and deleting invoices from the invoice file, and a recieptl library with functions specific to adding and storing PDF's as jpgs in the reciepts file, and so on. You can see an example of the reciepts file in my ScreenIO demonstration from the conference.
 
There is actually a bit of work that goes into Adding a new Reciept to the file. First I have to import it from a PDF (or Scan it from a scanner) and then I have to convert it to a JPG, and finally I store it in the Reciepts file, and then pass back the Key for the reciepts file to the calling program, so that it can use it wherever it needs.
 
I also have functions that return the path and filename of the jpg thumbnail for the purpose of displaying it on the screen.
 
I wrote all that code once, placed it in RecieptL, and then it was a simple drop in to place Actual PDF Documents in my Expenses, Invoices, and Company File, and any other places in the future that I find its necessary. Instead of writing to the file directly, I just say:
 
let Key$=fnAddReciept(Filename$;Scan)
 
And it automatically scans it, or imports it, or (if FileName$ is blank) opens up the BR File Selection Dialog and asks the user to select it.
 
When I want to display it, I simply say PRINT FIELDS "1,1,P 10/40" : fnShowReciept$(Key$)
 
 
Well, thats an overly simple example, but you get the idea.

Gabriel

On Sun, May 10, 2009 at 10:49 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
Thanks. I like the first idea as well. I already have my printing library pretty much cleaned up, so I'm part way down the road for that one. Maybe for any client-specific things, I'll just put the functions inside the appropriate general library (screen, print, acctspay, etc) and not worry about what client they are for. I can self-document those functions as to what client uses them and that way I can continue to use the same libraries across all clients. ("continue" is wishful thinking as I am not doing this now, which caused all of the problems with overlapping librarys in the first place!)

-- Susan


John Bowman wrote:
i'd seperate things by objective like

print.wb
screen.wb
accounting.wb
payroll.wb
array.wb

etc,,,  this helps make things easy to find and obvious where they belong...   or you might consider one big redirect library that points to everything.  and then each library have it's own .wb file.  this is great for limiting scope... but if you want your libraries to behave more like objects and share variables, than you can include just those libraries in a single .wb file.

i've worked all three of these ways with great success...  I think I like the first one the best... even if the libraries aren't sharing variables, it's most convient for me to have all my printing related libraries in one single print.wb, and it not be mucked up with array libraries or application specific processing (like payroll.wb)

2 cents,
-john

On Sun, May 10, 2009 at 10:54 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
MORE libraries or FEWER LIBRARIES?

I'm trying to reorganize my libraries because they are a mess. I'd love to find out how most of you set up your libraries. Do you use one library for screen routines and one for printing? Or possibly one general purpose library and one which is specific to different clients? I tried to do all of the above and now I can't seem to keep consistent libraries that make sense. There is a lot of overlap. I'd love the benefit of your experience.

I thought that it would make sense to have MORE libraries that were specifically tailored to narrower topics, but now I'm not sure. As many of you know, I don't have a vertical application. Each of my clients have a custom system. They COULD share some library code though, which is the point of course! But some routines will always be specific to one client. Should I just put everything in one library, including the client-specific stuff in case it might someday be used by a second client after all? Mix screen IO and printing? What to do with data-related routines? Thoughts? How do YOU determine how to structure your libraries?

-- Susan



_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

[BR_forum] Organizing Libraries

Post by Susan Smith »

These are good examples. I know I've been terribly remiss in my implementation of libraries. I do use then, but I should be placing many more "mini application" types of things in libraries for two reasons:
  • so they can be called from more than one program
  • so my calling programs can be more concise and easier to debug
-- Susan

Gabriel Bakker wrote:
I think you're on the right track with this now.

I often also have specific libraries for any data files that need more complicated logic associated with them. In my SageLive system I have an Invclib with functions specific to adding and deleting invoices from the invoice file, and a recieptl library with functions specific to adding and storing PDF's as jpgs in the reciepts file, and so on. You can see an example of the reciepts file in my ScreenIO demonstration from the conference.

There is actually a bit of work that goes into Adding a new Reciept to the file. First I have to import it from a PDF (or Scan it from a scanner) and then I have to convert it to a JPG, and finally I store it in the Reciepts file, and then pass back the Key for the reciepts file to the calling program, so that it can use it wherever it needs.

I also have functions that return the path and filename of the jpg thumbnail for the purpose of displaying it on the screen.

I wrote all that code once, placed it in RecieptL, and then it was a simple drop in to place Actual PDF Documents in my Expenses, Invoices, and Company File, and any other places in the future that I find its necessary. Instead of writing to the file directly, I just say:

let Key$=fnAddReciept(Filename$;Scan)

And it automatically scans it, or imports it, or (if FileName$ is blank) opens up the BR File Selection Dialog and asks the user to select it.

When I want to display it, I simply say PRINT FIELDS "1,1,P 10/40" : fnShowReciept$(Key$)


Well, thats an overly simple example, but you get the idea.

Gabriel

On Sun, May 10, 2009 at 10:49 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
Thanks. I like the first idea as well. I already have my printing library pretty much cleaned up, so I'm part way down the road for that one. Maybe for any client-specific things, I'll just put the functions inside the appropriate general library (screen, print, acctspay, etc) and not worry about what client they are for. I can self-document those functions as to what client uses them and that way I can continue to use the same libraries across all clients. ("continue" is wishful thinking as I am not doing this now, which caused all of the problems with overlapping librarys in the first place!)

-- Susan

John Bowman wrote:
i'd seperate things by objective like

print.wb
screen.wb
accounting.wb
payroll.wb
array.wb

etc,,, this helps make things easy to find and obvious where they belong... or you might consider one big redirect library that points to everything. and then each library have it's own .wb file. this is great for limiting scope... but if you want your libraries to behave more like objects and share variables, than you can include just those libraries in a single .wb file.

i've worked all three of these ways with great success... I think I like the first one the best... even if the libraries aren't sharing variables, it's most convient for me to have all my printing related libraries in one single print.wb, and it not be mucked up with array libraries or application specific processing (like payroll.wb)

2 cents,
-john

On Sun, May 10, 2009 at 10:54 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:


Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

[BR_forum] Organizing Libraries

Post by Gabriel »

And (3) what I consider to be the main benefit of libraries - you fix a bug once its fixed all over your application suite.
 
Example, I fixed the speed problems in the FileIO library and now all the applications I have written in BR for the last four years all the sudden run much faster.
 
Another example is when something in BR changes, if the offending lines are in a library I can fix them once instead of fixing them in all my programs.
 
Gabriel


On Tue, May 12, 2009 at 12:05 PM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
These are good examples. I know I've been terribly remiss in my implementation of libraries. I do use then, but I should be placing many more "mini application" types of things in libraries for two reasons:
  • so they can be called from more than one program
  • so my calling programs can be more concise and easier to debug
-- Susan


Gabriel Bakker wrote:
I think you're on the right track with this now.
 
I often also have specific libraries for any data files that need more complicated logic associated with them. In my SageLive system I have an Invclib with functions specific to adding and deleting invoices from the invoice file, and a recieptl library with functions specific to adding and storing PDF's as jpgs in the reciepts file, and so on. You can see an example of the reciepts file in my ScreenIO demonstration from the conference.
 
There is actually a bit of work that goes into Adding a new Reciept to the file. First I have to import it from a PDF (or Scan it from a scanner) and then I have to convert it to a JPG, and finally I store it in the Reciepts file, and then pass back the Key for the reciepts file to the calling program, so that it can use it wherever it needs.
 
I also have functions that return the path and filename of the jpg thumbnail for the purpose of displaying it on the screen.
 
I wrote all that code once, placed it in RecieptL, and then it was a simple drop in to place Actual PDF Documents in my Expenses, Invoices, and Company File, and any other places in the future that I find its necessary. Instead of writing to the file directly, I just say:
 
let Key$=fnAddReciept(Filename$;Scan)
 
And it automatically scans it, or imports it, or (if FileName$ is blank) opens up the BR File Selection Dialog and asks the user to select it.
 
When I want to display it, I simply say PRINT FIELDS "1,1,P 10/40" : fnShowReciept$(Key$)
 
 
Well, thats an overly simple example, but you get the idea.

Gabriel

On Sun, May 10, 2009 at 10:49 AM, Susan Smith <susan@creativelyspeaking.net (susan@creativelyspeaking.net)> wrote:
Thanks. I like the first idea as well. I already have my printing library pretty much cleaned up, so I'm part way down the road for that one. Maybe for any client-specific things, I'll just put the functions inside the appropriate general library (screen, print, acctspay, etc) and not worry about what client they are for. I can self-document those functions as to what client uses them and that way I can continue to use the same libraries across all clients. ("continue" is wishful thinking as I am not doing this now, which caused all of the problems with overlapping librarys in the first place!)

-- Susan

John Bowman wrote:


_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
Post Reply