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:
Thanks for any help or references! I apologize if the answer is "read more!"
>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
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!
Flag this post as spam/abuse.
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.
"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.
[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.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
+ 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
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.
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)
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
Flag this post as spam/abuse.
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.
Flag this post as spam/abuse.
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.
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 ;-).
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
[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.
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!
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...
@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.
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.
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
>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
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!
Flag this post as spam/abuse.
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!