The OpenEdge Hive

It is a nice idea, but I despair of how to tell layer from layer except by naming conventions that I would find unacceptable. One might come up with a simple rule or two, like no UI in any module that also contains DB access, but I am skeptical of being able to tune this very finely. Note also that one has cases like domain objects which travel between layers.

The usecase I was thinking about, is an OERA (or actually OESDK) appserver. It has business entities which are made up of at least two classes: one derived from the BusinessEntity class and one derived from the DataAccess class. The BusinessEntity child is supposed to have no database access at all.
But, since the BE child references the DA child, they both have to run in the same OpenEdge session which has to have a connection to the database. There does not seem to be a way to run or compile the BE layer with no databases connected, even if code in that layer does not access the database!!!

I have found that it is sometimes productive to write some FIND and FOR EACH stuff in the BE child, just to see if it produces the required results, and then refactor the db-access away to the DA child. Because it is productive, it is also dangerous: the danger is that you forget to refactor a bit, by accident or because you're in a hurry for a really quick fix and have no time to do it right.
And now I want Prolint to test this.

Well, I believe a naming convention might not be so bad, when those conventions are configured by directory. While subdirectories inherit (and optionally override) the configurations from their parent directory. Something like how Apache parses .htaccess files, but without the geeky syntax.

That way, one could easily configure that everything matching "appserver/dataaccess/*" may have access to the database, and all other programs may not.

Implementation: the configuration files needed to configure this, must be located somewhere in the Prolint directory - not in the directory where the sources are that need to be inspected. That way they can be made read-only for regular programmers and read-write for Prolint configurators.

I wonder if it should be possible to configure this by profile or simply globally. Comments?

> Naming convention by directory would do me no good since I put everything
> about Customer in com/cintegrity/IS/AR/Customer. I think that
> dividing the Customer stuff all over the place by presumed layer groups
> would make it much harder to look at Customer.

Yeah, that's certainly true. I have been wondering which would be more
convenient: directories for each layer/partition ("interface", "bl/be",
"bl/bt, "da" etc) or by entity. It both sucks, but I am still thinking
towards divisions by layer. Interesting discussion, but perhaps better to
continue somewhere in the OERA group.

> While it doesn't help for large bodies of existing code, I can see that it
> might be acceptable to include a ProLint "hint" in a comment at
> the top of the file which indicated which ruleset(s) were to apply to it
> based on layer.

Ok, but that would be a different feature request for a different
requirement :-)

What we really seem to need, is a way to have a rule-set by class (or
program type). But how?

> Interesting discussion, but perhaps better to
> continue somewhere in the OERA group.

As much as I would like to expand the use of OE Hive, this seems like a topic which deserves a broader audience and, hopefully, the participation of the AutoEdge architects since they have actually published some documents on the topic, so I started a thread at PSDN.

http://www.psdn.com/library/thread.jspa?threadID=2738

> What I was attempting to suggest was that the hint indicate the class ...

In the meantime we have learned that Proparse can, for a given OOABL class file, determine the list of inherited classes (and implemented interfaces too, I suppose). So one possible rule could be that a class should not be allowed to access a database unless one of its ancestors is class "DataAccess". Where the string literal "DataAccess" should be configurable of course.
Is that an acceptable idea?

If one implements a generalized feature in which a hint can indicate a particular rule set and also implements that, for classes, a hint in any ancestor class is equivalent to having the hint in the current class, then I think one would have a very powerful mechanism that required relatively little effort to implement. For .p code, one would still have to update every program, unfortunately, but anyone working with OO would be in great shape to take advantage of this.

I would make this entirely general purpose. I.e., the mechanism merely consists of logic such that, if the hint is present, then a particular block of rules is applied, otherwise it isn't. This can be used for the purpose which stimulated this discussion, but it could also be used for any other purpose, e.g., special rules to apply to programs containing socket code or webservices code or Sonic code, etc.

What would happen if there was a "conflict", e.g., a class ancestor says data access and a child says UI? I don't think I would report this as an error in itself, exactly because I think it is more powerful if we think of it in terms of attributes, of which multiple might apply to one file. I think this would resolve itself fast enough because the report would be full of both X is bad because this is DA and Y is bad because this is UI and it would be apparent that one had screwy hints.

Thus, one might have hints for UILayer, ChUI, GUI, and WUI and they are all different sets of rules.