Use this thread to discuss anything about AutoEdge. Design decisions, implementation choices, things you liked, things you'd do differently.
Also, feel free to start a new thread if you think the topic is big enough to stand on it's own. Just put "AutoEdge" in the subject so we can easily spot them.
Having gotten the code installed, I saw references like this:
Why the period after the include spec?
Another thing - this code appears to have tabs in it as opposed to being all space-aligned.
What tab stops was used when writing this?
I am curious about the design choice which leads to a PROPATH of
and so forth, quite a few directories and a fair number of them nestled within themselves.
My own inclination would have been to have at most one base directory per UI plus one shared and to have all paths within the code relative to those bases. I.e., within server, you have a bunch of directories. The paths in the code to all of the programs in all of those directories except oeri are preceded by the directory name. Why make oeri different. Likewise for gui where two of the directories are in the propath directly and the rest aren't.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
The paths in the code to all of theprograms in all of those directories except oeriare preceded by the directory name. Why make oeridifferent. Likewise for gui where two of thedirectories are in the propath directly and the rest aren't.
The paths in the code to all of the
programs in all of those directories except oeri
are preceded by the directory name. Why make oeri
different. Likewise for gui where two of the
directories are in the propath directly and the rest
You mean like
I am guessing that the program naming convention used in AutoEdge, i.e. beXXX, daXXX, dsXXX, etc. derives from or is the basis from which the naming convention in the OERA white papers.
With the application now out the door, how do you feel about this naming convention?
I ask because my own inclination is to name so that things are grouped by the entity, not by the layer. Also, I would tend to create subdirectories for each entity. E.g. server\autoedge has 88 files in it, despite a relatively simple schema. For an ERP application, there would be thousands of files in this one directory. Thus, I would have been inclined to put all of the files relating to car in the autoedge\car directory. I am currently inclined to Car.cls, CarFinder.cls, and CarMapper.cls, or, in your case CarBE.p, CarDA.p, CarDS.p, but even if you use the prefix standard, there would be a limited number of files in the autoedge\car directory.
Within autoedge\src\server, there are directories autoedge, crystal, oeri, oerpcore, proxy, services, setup, sonic, test, and webservices. The propath is to the server directory and to the oeri directory within server. in the case of autoedge\src\gui, there are directories for autoedge, controls, img, oeri, pure4gltv, and services and the propath is to the gui directory and also to the oeri and pure4gltv directories within gui. Seems inconsistent.
Not having been involved in the design myself, I'm guessing the main reason for this approach was to be able to keep the "framework" things separate from the application itself.
"framework" things including:
- oeri - OpenEdge Reference Implementation
- pure4gltv - a pure 4GL/ABL Tree View for GUI
- escript - the eScript WebObject)
As a learning tool, it's very useful to keep such things separate so that the development community could take the "framework" things and modify them for their own use.
It is expected that people will modify certain programs. Such changes should actually be made in the \src directory. For people who do this, the propath could well end up being twice as long.
I don't think that such a long propath is really good practice for a deployment environment, but then there are other possibilities for deployment. One could put all the .r's in a single directory or could put them into a procedure library (that might be memory-mapped on the server side).
I think there are a number of valid choices here. I see your point about separating the business entities into their own directories. From a development perspective, you could use the Eclipse "Working Sets" to make sure you only see the files related to your single business entity.
With the current implementation some files (temp-table.i, xxSupport.i) are used by multiple business entities. One side effect of the current directory structure is that you don't have to decide which single business entity these files belong to.
I know, this isn't how you understand encapsulation and some of this might go away with a class based implementation, but I could still imagine that some objects might actually benefit from putting their temp-table definitions in an include file. (I'm relatively new to OO. Perhaps this is a debate for another thread)
One thing I wouldn't want to do is to confuse the server side components with the client side components. Keeping them separate makes it a whole lot easier at deployment time. That said, tools like RoundTable can help to make sure that the right components get deployed to the right environments for runtime.
I'm guessing the main reason for this approach was to be able to keep the "framework" things separate from the application itself.
A fine notion. But, if the path reference in the code is to "oeri/neatThing.p" instead of simply "neatThing.p", then the additional PROPATH entry pointing to oeri is unnecessary.
If anything, I would rearrange so that we had the UI specific stuff under one base directory, the actual application code under a second base directory, and the framework stuff under a third base directory. These three base directories would be the PROPATH and all files would be in subdirectories under one of these base directories and the name of the subdirectory would be in the path reference in the code.
FWIW, I would also divide up the application code this way by entity, i.e., all of the Car related stuff in a Car subdirectory.
I am all in favor of separation. In my own application suite, there are rarely more than 10 or 20 files in a given subdirectory. This doesn't preclude functions which utilize files from multiple subdirectories. For example, in this application suite ... which is .p based ... there is a subdirectory for order processing. Within that there is a directory which is the base for the order entry function. That function uses code in several library subdirectories, e.g., op/orde/ordepo.p might reference op/olib/something.p or op/alib/something.p where op/olib is a set of general routines which apply to orders and op/alib is a set of routines which relate to allocation. Both libraries are referenced in a number of functions in multiple subdirectories.
And, as I say, I have no objection to having more than one base directory, e.g., for application versus framework, but I don't think one should have both the base directory and a subdirectory within that base directory both in the PROPATH.
Note, for example, that something in the oeri subdirectory can be found either by referring to oeri/neatThing.p or just neatThing.p ... what an interesting wrinkle that must be for doing call analysis!
Ok, As someone who was very much involved in the decisions, let me try and explain some of the thinking.
Firstly lets state up front that one of the aims of AutoEdge is as a teaching aid, and as such doesn't always reflect what one might do in the 'real' world. The propath is one of these areas, there are others. For example, when it comes to managing error messages, we show two approaches to achieve the same result, simply to show that there are multiple ways to achieve the same thing. You'd like to think that in a real application, you do it one way, consistently!
Jamie is right when he says one of the reasons for the propath structure was to seperate the architecture code from the application code. A second choice was that we wanted to try and make it clear what code came from the original 'Implementing the OERA' work and to keep that as close to the orginal download as possible, to also then make it easier for people to see what we'd changed in relation to that code. This explains the ../oeri portion of the propath.
This thinking was then applied to other areas, so for example you will see if you look at the HTML based code, that we used the eScript web object to handle the merging of the HTML and ABL code. We didn't want to modify the eScript code in case there were future updates, so again this forced a certain propath structure. This, as Jamies rightly points out also applies to such things are the 4GL Treeview etc.
In addition, we wanted to keep the code for the vaious client types seperate from the server, so again hence the propath that you see.
So in summary, is the Propath a little quirky compared to what you'd do for 'real', probably, but in my 16+ years working with Progress, I can promise you I've also seen worse in the 'real world'
I appreciate the pedagogic value of showing more than one way to do something. I am less sure that I would actually deploy competing methods in even a sample application. Instead, I would tend to create a white paper with code which showed both methods and then pick one as the superior method and use it in the application.
I have spent some time looking at proException.p and expect to comment on it one of these days soon. Can you point me to the core of the other method?
I still don't buy the structure of the PROPATH. If you want to leave certain pieces clearly separate, then do something like
to clearly separate out parts of the application that come from outside and which might be upgraded. But, put the PROPATH to src/framework and reference oeri/neatThing.p in the code. If you can't do this for some reason, then at the very least make it src/oeri and src/pure4gltv so that you don't have a PROPATH which has nested directories. With nested directories you have the potential for ambiguous references ... ugly, even if it has no practical consequence.
So, I can see a PROPATH which was
or something to that effect, but not this nesting. I think this provides all the separation and isolation that one needs without having such a horrific PROPATH.
I can promise you I've also seen worse in the 'real world'
I'm sure you have ... but I think that one should recognize that sample code coming from PSC gets looked at as a guide to how to do things ... even when it is small isolated code fragments in a manual. How much more will AutoEdge be looked at this way because it is such a rich example ... clearly lots of thought has gone into it, so it must be a good example, mustn't it?
I have spent some time looking at proException.p andexpect to comment on it one of these days soon. Canyou point me to the core of the other method?
I have spent some time looking at proException.p and
expect to comment on it one of these days soon. Can
you point me to the core of the other method?
It's actually mentioned in the 'Design Decisions' section at the end of the Business Entity Paper (http://www.psdn.com/library/entry.jspa?externalID=1444&categoryID=302).
Thanks ... I'll take a look.