Static Class Code Libraries (or Smarter Ways to Manage Busin

Posted by bgourdie on 13-Oct-2014 16:01

Hello, pretty new to 4GL and this site. Searched a bit but couldn't seem to find anything I need.

My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).

Coming from a college Java background, static classes (like Java.Math) make more sense to me, as .R code size is rapidly becoming an issue, and I think that compiled classes would exist in their own .R files (right? I couldn't find anything contrary to that point).

The end goal, from what I can tell, is:

  • First and foremost, a structured library of functions to prevent re-inventing the wheel
  • Compile-time argument checking (.p run-time argument checking is tedious)
  • Easy compilation maintenance (keeping track of what uses Function F and recompiling everything seems tedious)
  • Encapsulated (include files can't use same variable names as main programs is one "gotcha" we found)
  • Ease of or even self-documentation (just found out about prototypes today but I'd prefer private methods instead of saying "don't use this function")

Thanks for any help or references! I apologize if the answer is "read more!"

Posted by Peter Judge on 14-Oct-2014 11:45

>We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown
> Eclipse and were not impressed, though I have years of experience with it for Java.

Later versions of PDSOE (the new name for OE Architect) are much better in the 11.x family – better functionality, better performance. There is, of course, nothing preventing you from using N++ or Sublime Text or a bunch of other editors, and compiling using Ant or something similar.

> The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we
> would use an object (ideally).

Easily doable in OOABL (ooh-able?). Even in 10.2B, IIRC.

>That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight.
>Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer
>muses solutions that beg for OO but he is not too familiar with it.

One of the great things about OOABL is that it coexists almost perfectly with procedural ABL, and I suspect that most procedural ABL programmers would easily be able to use objects in their code (there are already analogues like using the SESSION handle or THIS-PROCEDURE or whatnot, which have properties/attributes and methods on them).

Adding new utilities or encapsulating existing libraries in OO might be a good way to introduce OO into your applications. There are also usually one or more talks and workshops at the PUG Challenges and Progress Exchange on getting started with OO (Tim Kuehn has a perpetually-popular workshop on this).

For content from the US event, go to http://pugchallenge.org/downloads.html  (many years' worth). For the EU version, http://pugchallenge.eu/sessions_2013.html for last years' content (this is one area where the US version beats the EU version :)

>So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given >some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like
>FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be
>very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

If you have Java experience designing business app you should be good. The language reads very much like Java or C# and has most of the functionality those languages do (there are certainly exceptions, some large, but generally you should be able to Get Stuff Done).

The other thing you will miss is the availability of public, commonly-used class libraries to help you do things like ORM or whatnot.

HTH,

-- peter

 
 
 
 
[collapse]
From: bgourdie [mailto:bounce-bgourdie@community.progress.com]
Sent: Tuesday, 14 October, 2014 10:38
To: TU.OE.General@community.progress.com
Subject: RE: [Technical Users - OE General] Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
 
Reply by bgourdie

Sorry for the lack of information; I wanted the first post to be short enough.

We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown Eclipse and were not impressed, though I have years of experience with it for Java.

We are not using an Appserver nor even SmartObjects. Everything is run off a server using a terminal (old system) or icons pointing to graphical programs and reports (new system). I don't really know what else to say here.

The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we would use an object (ideally).

That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight. Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer muses solutions that beg for OO but he is not too familiar with it.

So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

Thanks for all the thoughtful conversation and links!

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

All Replies

Posted by Tjerk Coomans on 13-Oct-2014 16:52
Hi,
You can use classes and write Object Oriented code in the OpenEdge ABL.
See link to the manual.

Which OpenEdge version are you using?
Which tool are you using to write or maintain your code?

Currently the preferred way is using "Progress Developer Studio for OpenEdge". This is an eclipse based development environment.

Kind regards
Tjerk
Posted by Tim Kuehn on 13-Oct-2014 17:04

You need to bring in someone who'se done the kind of code modernization you're working on. For one, I would strongly suggest you put all your functions in classes as methods instead of using include files - this will make life a _lot_ easier down the road.

As for static classes - they have their place, however because their lifecycle is scoped to the session, they bring a number of issues with them that you'd be better off avoiding wide-spread use of them.

Posted by Mike Fechner on 14-Oct-2014 00:28

"I think that compiled classes would exist in their own .R files (right? I couldn't find anything contrary to that point)."

You are absolutely right with that observation. Each class is compiled into it's own R-Code.

Posted by Mike Fechner on 14-Oct-2014 00:31
[quote user="Tim Kuehn"]

As for static classes - they have their place, however because their lifecycle is scoped to the session, they bring a number of issues with them that you'd be better off avoiding wide-spread use of them.

[/quote] I have the impression that the OP has experience with static classes in Java. They have their place there and here. For utility classes (that become part of the extensions of your personal ABL) they are a good vehicle. And the life time is typically not an issue for those classes as you need them the whole duration of the application anyway.
Posted by agent_008_nl on 14-Oct-2014 01:55

I share Tim's concern. Mike is right, but OP suggests the use of static classes as a replacement for more than just utility classes I fear. A lot more is possible with the 4GL, I recommend OP to take a look at the possibilities of an inversion of control container (open source) and dependency injection written in 4GL:

community.progress.com/.../998.oeri-dependency-injection-container-injectabl.aspx

github.com/.../InjectABL

+ the autoedge|the factory framework (for coding examples):

community.progress.com/.../974.autoedgethefactory-getting-started.aspx

--

Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Posted by Mike Fechner on 14-Oct-2014 02:02
I didn’t expect you not to disagree with me. Beg my pardon, when I get the feeling that the OP has OO experience, I tend not to put his question down like a stupid boys question like some others tend to do in forums.
 
But I must say it really surprises me, that you put the math capabilities of the  ABL (the OP’s sample) above the math capabilities of the OP.
 

Posted by agent_008_nl on 14-Oct-2014 02:26

Mike, an invitation for a mudfight to me personally is not in the interest of OP. You purposely misinterpret my intentions.

OP states "My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).". Het proposes to use static classes instead. A pointer to some more possibilities of the 4GL is not that bad, is it? After all he states himself he is pretty new to 4GL.

Posted by Tjerk Coomans on 14-Oct-2014 04:36

Hi Bret,

Is someone guiding you to modernize the application? Since you are new to 4GL/ABL it would be good to set the basics correct and talk through the do's and don'ts.

Did you hear about OERA (OpenEdge Referential Architecture).

It scares me a bit that your company still uses include files to define utility or helper functions/methods. But if I read your post it also scares you a bit :).

I agree with Mike and Tim. Static methods are great to use but need to be used carefully. A common mistake here is not define correctly record scopes. In general I would say use static methods for utility classes where you don't have data access. When you have data access it would be better to have business entities and an implementation of singleton classes. (OERA)

Posted by Tim Kuehn on 14-Oct-2014 05:09
On Tue, Oct 14, 2014 at 3:02 AM, Mike Fechner
wrote:
> I didn’t expect you not to disagree with me. Beg my pardon, when I get the
> feeling that the OP has OO experience, I tend not to put his question down
> like a stupid boys question like some others tend to do in forums.

The OP may have OO experience, however there are run-time
considerations when doing ABL code which are different from Java
run-time considerations. For instance, upgrading an appserver-based
application, where the "scope of the session" is the agent's lifetime,
not a single user's session. Using statics in that scenario has caused
lots of problems when it's time to replace static-based or dependent
code with something else, particularly if TT changes are involved.

--
Tim Kuehn: Senior Consultant - TDK Consulting Services
Ontario PUG President
PUG Challenge Americas Executive, Program Committee Chair

Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Posted by Mike Fechner on 14-Oct-2014 05:28
I still believe we need to learn more from the OP about what he intended in those statics.
 
What runtime considerations are you talking about ABL vs. Java that are relevant for static classes in particular? The ABL is slower in loading classes compared to Java and .NET. That’s a fact and that leads to a more important role of temp-tables and ProDatasets in modern architectures.
 
But especially with static classes, the overhead in instantiation is pretty much ignorable.
 
We use a hand full of utility classes that are static. We consider them extensions of the language. And I don’t have problems with that.
All framework and business logic classes are non static. That’s a different domain and can IMHO be implemented differently.
 
Von: Tim Kuehn [mailto:bounce-timk519@community.progress.com]
Gesendet: Dienstag, 14. Oktober 2014 12:10
An: TU.OE.General@community.progress.com
Betreff: Re: [Technical Users - OE General] AW: Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
 
Reply by Tim Kuehn
On Tue, Oct 14, 2014 at 3:02 AM, Mike Fechner
wrote:
> I didn’t expect you not to disagree with me. Beg my pardon, when I get the
> feeling that the OP has OO experience, I tend not to put his question down
> like a stupid boys question like some others tend to do in forums.

The OP may have OO experience, however there are run-time
considerations when doing ABL code which are different from Java
run-time considerations. For instance, upgrading an appserver-based
application, where the "scope of the session" is the agent's lifetime,
not a single user's session. Using statics in that scenario has caused
lots of problems when it's time to replace static-based or dependent
code with something else, particularly if TT changes are involved.

--
Tim Kuehn: Senior Consultant - TDK Consulting Services
Ontario PUG President
PUG Challenge Americas Executive, Program Committee Chair

Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by Mike Fechner on 14-Oct-2014 05:30
Stefan, despite your usual unqualified „Bratwurst“ vs. “Frikandel” posts you won’t get me down on that level.
Not sure what you refer to.
Von: agent_008_nl [mailto:bounce-agent_008_nl@community.progress.com]
Gesendet: Dienstag, 14. Oktober 2014 09:27
An: TU.OE.General@community.progress.com
Betreff: RE: [Technical Users - OE General] Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
 
Reply by agent_008_nl

Mike, an invitation for a mudfight to me personally is not in the interest of OP. You purposely misinterpret my intentions.

OP states "My company is currently rewriting programs to GUI and trying to re-architecture the code base along the way. We are currently writing Functions inside of Include Files, grouped by category (convert temp table to .CSV, determine X/Y/Z of F, etc).". Het proposes to use static classes instead. A pointer to some more possibilities of the 4GL is not that bad, is it? After all he states himself he is pretty new to 4GL.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Posted by agent_008_nl on 14-Oct-2014 05:59

I'm not trying to get you down (I refused the mudfight, didn't I).  You take offence too quick.  A bit of humour please.  For the rest I leave your personal comments here for what they are, in this thread.

Posted by agent_008_nl on 14-Oct-2014 07:01

OERA is good to name. Very short on that: www.progress.com/.../ds-OpenEdge-Reference-Architecture.pdf

There are several frameworks written according to it, like the autoedge|the factory (the most intelligent written one that I saw, I based mine on the backend part of it). Opensource: http://www.quarix.net/

And of course there are several of these frameworks for sale (mine also ;-).

Posted by Mike Fechner on 14-Oct-2014 07:08
Depending in which geography you live, you might register for the EMEA PUG Challenge conference (standard registration closing tomorrow): http://pugchallenge.eu
The conference is a great place to learn about OOABL, modernization options, frameworks ...
A few framework vendors will also be exhibiting and presenting there.

 

Posted by Tim Kuehn on 14-Oct-2014 07:16
On Tue, Oct 14, 2014 at 6:28 AM, Mike Fechner
wrote:
> I still believe we need to learn more from the OP about what he intended in
> those statics.

More information is always good.

> What runtime considerations are you talking about ABL vs. Java that are
> relevant for static classes in particular?

Upgrading systems running "old" appservers.

> We use a hand full of utility classes that are static. We consider them
> extensions of the language. And I don’t have problems with that.

It depends on how the OP designs his system, where the statics are
used, and what kind of upgrade mechanism they follow. As I mentioned,
the static lifecycle is to the appserver agent's life, not the user's
session life, which makes upgrading them problematic. This was from a
conversation I had with Mary a while ago where I related that losing a
db connection resulted in a session reset for connect clients, and she
wondered if that could be used to upgrade appserver agents.


--
Tim Kuehn: Senior Consultant - TDK Consulting Services
Ontario PUG President
PUG Challenge Americas Executive, Program Committee Chair

Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Posted by Mike Fechner on 14-Oct-2014 07:40
“Upgrading systems running "old" appservers.”
 
Not sure what you mean with „old“ AppServers.
 
You think trimming AppServer agents every now and then is a bad thing? If it’s static or not – if you load classes into the memory of the AppServer and don’t know which classes in memory are from which release of the server code base (some loaded before your on the fly update, some loaded after your on the fly update) that sounds like a nightmare came true.
 
On the other hand, the nature of the static utility classes may allow to update them less frequently than actual business logic. So once a year, I believe that trimming AppServer agents is o.k.. Others may actually be using the auto-trim feature of AppServer agents – without lacking any scalability.
 
Aren’t we making too much assumptions already about what the poor OP is intending to do?
 

 

 

Posted by Tim Kuehn on 14-Oct-2014 07:52

[quote user="Mike Fechner"]

“Upgrading systems running "old" appservers.”
 
Not sure what you mean with „old“ AppServers.
[/quote]
 
As opposed to the next-gen appserver PSC announced at Exchange.
 
[quote user="Mike Fechner"] 
You think trimming AppServer agents every now and then is a bad thing? If it’s static or not – if you load classes into the memory of the AppServer and don’t know which classes in memory are from which release of the server code base (some loaded before your on the fly update, some loaded after your on the fly update) that sounds like a nightmare came true.[/quote]
 
I'm going by what Mary told me - that upgrading appservers with static class code operational on them was a problem. I know that statics can also cause issues for sites that use "on-the-fly" upgrade scenarios as well. 
 
[quote user="Mike Fechner"] 

On the other hand, the nature of the static utility classes may allow to update them less frequently than actual business logic. So once a year, I believe that trimming AppServer agents is o.k.. Others may actually be using the auto-trim feature of AppServer agents – without lacking any scalability.[/quote]

/If/ that's how they're used in the system. If someone uses statics for business logic, etc. then the story gets more complicated. 

 
[quote user="Mike Fechner"] 
Aren’t we making too much assumptions already about what the poor OP is intending to do?
[/quote]
Not really, this is just relating some potential issues to look out for.
I'm a bit surprised Julian hasn't weighed in with his experiences yet....
Posted by Mike Fechner on 14-Oct-2014 08:02
Not really, this is just relating some potential issues to look out for.
 
So making assumptions ;-)

Posted by bgourdie on 14-Oct-2014 09:36

Sorry for the lack of information; I wanted the first post to be short enough.

We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown Eclipse and were not impressed, though I have years of experience with it for Java.

We are not using an Appserver nor even SmartObjects. Everything is run off a server using a terminal (old system) or icons pointing to graphical programs and reports (new system). I don't really know what else to say here.

The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we would use an object (ideally).

That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight. Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer muses solutions that beg for OO but he is not too familiar with it.

So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

Thanks for all the thoughtful conversation and links!

Posted by andrew.may on 14-Oct-2014 09:51

The pre-OO way of doing this would be to have the util code running in persistent procedures & for individual programs to run internal procedures or functions in those libraries

e.g. create a library “libMath.p"

then in client code...

DEF VAR hLibMath AS HANDLE NO-UNDO.

RUN libMath.p PERSISTENT SET hLibMath.


/* ... snip ... */
 
RUN toRadians IN hLibMath (INPUT degrees, OUTPUT radians).

/* or ... */

radians = DYNAMIC-FUNCTION("toRadians" IN hLibMath, INPUT degrees).


N.B. you'll have to consider how to manage the lifecycle of the persistent procs.  

some options to consider are... 

  • load them as session super-procs & leave them running for the lifetime of the session.
  • have some library-manager that loads & passes out proc-handles to procedures that need to use a library
  • start them at the top of a ".p" & clean them up in FINALLY blocks
Posted by gus on 14-Oct-2014 09:54

@bgourdie: note also that you can mix object programming and traditional procedural programming as needed. so you don't have to remake the entire application at once just because you want a few static classes.

also, if you don't want to do objects for some reason, you can use external procedures. that is a much better solution than include files and gives you one copy of the utility functions.

in your future, use of include files should be mostly avoided as should use of the preprocessor. there will be exceptions of course.

Posted by Thomas Mercer-Hursh on 14-Oct-2014 09:56

If you reference the static method in ABL (there are no static classes, only classes with all static members), it will be instantiated and will live in memory for the duration of the session.  That can be a good thing, but use with caution.

I would take a look at more recent versions of ABL and PDSOE.  You are missing a lot in 10.2B.

The issues with the DB can be minimized by creating a data access layer to separate access to the DB from the object model of the application.

You really, really, really want to get an AppServer in the mix.

I would strongly advise some consulting on the architectural model before you go very far.  Otherwise, you are likely to have a lot of rework and going down blind alleys.

I am going to guess that the old code is old enough not to have superprocedures either.  Otherwise, they are a possible model for using objects.

It is a perfectly fine idea to bundle a bundle of related logic into a class, instantiate it went appropriate, and use it in the fashion you indicate (except for wanting to separate the data access part).  But, apply principles of good OO design in what does and does not go into the class and pay attention to separation of concerns to minimize the dependent linkages.

One good use of a static is to provide a registry by which one object can find another object without having to know very much about it.  Dependency injection is another useful technique.

Posted by ChUIMonster on 14-Oct-2014 09:58
You might find this to be interesting:

http://pugchallenge.org/downloads2014/930_ooshrvar.pptx

the audio:

http://pugchallenge.org/downloads2014/930_How_I_Learned_to_Love_OO.mp3

There are updates coming in a couple of weeks.

--
Tom Bascom
603 396 4886
tom@greenfieldtech.com
Posted by Peter Judge on 14-Oct-2014 11:45

>We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown
> Eclipse and were not impressed, though I have years of experience with it for Java.

Later versions of PDSOE (the new name for OE Architect) are much better in the 11.x family – better functionality, better performance. There is, of course, nothing preventing you from using N++ or Sublime Text or a bunch of other editors, and compiling using Ant or something similar.

> The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we
> would use an object (ideally).

Easily doable in OOABL (ooh-able?). Even in 10.2B, IIRC.

>That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight.
>Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer
>muses solutions that beg for OO but he is not too familiar with it.

One of the great things about OOABL is that it coexists almost perfectly with procedural ABL, and I suspect that most procedural ABL programmers would easily be able to use objects in their code (there are already analogues like using the SESSION handle or THIS-PROCEDURE or whatnot, which have properties/attributes and methods on them).

Adding new utilities or encapsulating existing libraries in OO might be a good way to introduce OO into your applications. There are also usually one or more talks and workshops at the PUG Challenges and Progress Exchange on getting started with OO (Tim Kuehn has a perpetually-popular workshop on this).

For content from the US event, go to http://pugchallenge.org/downloads.html  (many years' worth). For the EU version, http://pugchallenge.eu/sessions_2013.html for last years' content (this is one area where the US version beats the EU version :)

>So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given >some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like
>FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be
>very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

If you have Java experience designing business app you should be good. The language reads very much like Java or C# and has most of the functionality those languages do (there are certainly exceptions, some large, but generally you should be able to Get Stuff Done).

The other thing you will miss is the availability of public, commonly-used class libraries to help you do things like ORM or whatnot.

HTH,

-- peter

 
 
 
 
[collapse]
From: bgourdie [mailto:bounce-bgourdie@community.progress.com]
Sent: Tuesday, 14 October, 2014 10:38
To: TU.OE.General@community.progress.com
Subject: RE: [Technical Users - OE General] Static Class Code Libraries (or Smarter Ways to Manage Business Logic)
 
Reply by bgourdie

Sorry for the lack of information; I wanted the first post to be short enough.

We are using OpenEdge 10.2B. Developing with Appbuilder for GUI, I use Notepad++ and the others use the Procedure editor for legacy code. We were shown Eclipse and were not impressed, though I have years of experience with it for Java.

We are not using an Appserver nor even SmartObjects. Everything is run off a server using a terminal (old system) or icons pointing to graphical programs and reports (new system). I don't really know what else to say here.

The static classes would be utility classes: final, private no-args constructor, and as such never instantiated. If we need to carry state, we would use an object (ideally).

That being said, I am the only programmer with OOP experience. If I propose an OO solution, I would meet with a lot of resistance even if it was air-tight. Besides, OO probably would not work with our DB model; it's like incorrectly normalized and would need rearchitectured separately. The managing programmer muses solutions that beg for OO but he is not too familiar with it.

So, right now we were considering having our business logic in these utility classes. I'm not sure why this would be a problem yet. We'd ask for a number given some arguments and be on our way. For example, "what is the weight of the finished material on the current order?" would be something like FinishedMaterial:weight(orderNum) which looks in the database, adds the numbers up, and returns it. The only disadvantage I see is that these classes will be very big and have a lot of methods to look through when trying to find if something had been done before. Perhaps I am just naive.

Thanks for all the thoughtful conversation and links!

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by bgourdie on 15-Oct-2014 11:14

I've marked this question as answered, as you all have given me a lot to think about. I'm going to pour over resources now, starting with the OOABL doc. Thank you everyone!

This thread is closed