OE10 - Best practice suggestions for source / object code folder organization
My OE10 arrived yesterday. I'd like to use this opportunity to better organize my source and object code folders. I have both GUI and CHUI code, and an increasing number of source and r-code files which are non-interactive and shared across the user interface environments.
Over the past decade (v8 through v9) I have organized my folders along the following lines:
src (CHUI and shared source)
- ap/
- ar/
- gl/
...
tty (CHUI and shared r-Code)
- ap/
- ar/
- gl/
...
gui (GUI Source AND Object)
- ap/
- ar/
- gl/
...
- viewers/
- windows/
each module (ap, ar, gl ... 20 of them) has dozens to hundreds of .p, .i and .w files.
This tree structure would appear below dev, test, and live higher level work areas.
Rather long and complicated PROPATH settings pick up the correct folders in the proper order, e.g.
for CHUI: .,./tty,./src,/test/tty,/test/src,/live/tty,live/src etc.
for GUI: .,./gui,./tty,./src,/test/gui,/test/tty,/test/src,/live/gui, etc.
This created problems in that the CHUI r-code had to be xcopy'ed from src to tty, and when editing a file from live or test I had to be careful to save it back into dev. A lot of folder traveral. And the uneasy feeling that when testing "Am I REALLY picking up the latest version?"
With OE10 I thought I would have a folder tree (call it src or common) for the shared source/object which would initially be all the triggers, and various procedures which have no user-interface component. Ultimately I want to have the "guts" of my report and posting programs (100's of them) in this common area. This would facilitate shared running of object code from both CHUI and GUI user interfaces, and allow the "guts" of the programs, the database intensive parts, to run on appservers and be called from Web.
I would move all the src/ code with frames or CHUI dependencies into TTY/, and move out of GUI/ into anything which has no UI and can be shared.
This way all r-code can be left "in situ" next to it's source, with no need to move it to another folder tree. Downside of that is that every change would need to be compiled (or NONE compile, working purely with session compiles), unless I continued to use a dev (/src, /tty, /gui) higher-level folder, but then I am back into folder traversal and very careful saving.
I would like to make use of the OE10 Architect and I noticed while playing with the test drive that it has it's own conception of all of this, with projects, workspaces, working sets, and so on.
Any suggestions as to best practice in this regard?
- Login to post comments
Re: Best practice for folder organization
Hi Christopher. Your folder organization sounds like it is similar to what many other developers do. Keeping your PROPATH reasonably short is always helpful.
Many shops have arrangements of folders depending on various influences. Those include the number of developers, the source code management tools being used, the kinds of deployments being done, the number of variations and configurations of the application, the development and analysis tools being used, and the inclusion of third party libraries.
In terms of moving forward, you might want to take a look at the way that OO classes are arranged, such as com/acme/ar/Invoice.cls.
The fact that you are using xcopy is a bit of a red flag. At any time, your code management tools should be able to generate any version of any configuration of any variant of your application. For any of these that is being used (in testing or in production), you want to be able to generate it from your source control tool, and be able to perform complete analysis on it, such as system wide XREF or grep or parse.
At the time that you update a snapshot with new or modified source code, you would want to do a re-compile and update any code search indexes such as XREF tables.
You are going in a good direction when using directories to separate common code from GUI code from TTY code.
I doubt this has been much help, but hopefully you have a bit of a better feeling that yes, other people are doing similar things, and also it's hard to describe 'best practices' for this sort of thing because there are so many influencing factors.