P
Peter Judge
Guest
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 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) RE: 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.
Continue reading...
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 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) RE: 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.Continue reading...