AutoEdge - Discussion - Forum - OpenEdge Architecture - Progress Community
 Forum

AutoEdge - Discussion

  • Well, I guess I would say, positive points for including it in the discussion, but negative points for including it in the code. I think that the sentence from that doc which says "The standard and preferred way is to use the addError() routine" pretty well says it all...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Well, I guess I would say, positive points for

    including it in the discussion, but negative points

    for including it in the code. I think that the

    sentence from that doc which says "The standard and

    preferred way is to use the addError() routine"

    pretty well says it all...

    Well, as I said earlier, the aim is to show mutiple ways, but then if we feel ome just makes more sense, then point that out. Not everyone may have implemented a form of formal error handling in their application, and so the alternative approach maybe a valid choice in that situation. The main thing is it's documented

  • Myself, I would focus on showing them how they could bolt on formal error handling to an application that doesn't have it now and gradually utilize it as opportunity presents.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Well, speaking of the error handling, let's talk about proException.p a little.

    And, let me be frank up front about my aversion to the preprocessor, even though there are places where I have been forced to use it myself as the lesser of evils.

    One piece I am curious about is why you have rather slavishly copied the Java exception handling? To be sure, it is the obvious model, but I would have thought that the history of ABL error handling was focused on the block and so it might have incented you to think in terms of block structured exception handling.

    Something makes me nervous about raising STOP all the time ...

    Any reason you did not provide temp-tables so that one could stack multiple errors?

    It seems like there are an awful lot of entry points ...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Let me guess that this one preceded 10.1A?

    PROCEDURE getUUID :

    /*

    Purpose: Generates a Universally Unique Identifier.

    Parameters: OUTPUT pcUUID

    Notes:

    */

    DEFINE OUTPUT PARAMETER pcUUID AS CHARACTER NO-UNDO.

    pcUUID = GUID( GENERATE-UUID ).

    END PROCEDURE .

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • The naming convention used in AutoEdge for program units, variables, and such seems to derive at least in part from the one used in John Sadd's whitepapers. Two questions:

    1. Has this standard been codified in a document so that one can look at it rather than having to deduce it?

    2. From an earlier exchange I got some indication that perhaps, now that AutoEdge was done, there might be some second thoughts about the standard, e.g., beXXX causes all be units to sort together rather than the various units associated with one entity. Is this more than a niggling doubt in the minds of isolated developers? Does anyone have a new set of proposals?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • After some distraction, I am now back ready to do a bit of code reading. Is there an interest and willingness on the part of PSC to engage in a bit of "code review"? I.e., to discuss why certain design choices were made, what alternatives might have been considered and discarded, whether a particular alternative was considered, what advantages and disadvantages one might see, etc.

    I think this would be illuminating to a lot of us.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 1. Has this standard been codified in a document so

    that one can look at it rather than having to deduce

    it?

    There is a programming standards document available within the AutoEdge documentation in the Documentation > Project directory.

  • Let me guess that this one preceded 10.1A?

    PROCEDURE getUUID :

    /*

    Purpose: Generates a Universally Unique

    e Identifier.

    Parameters: OUTPUT pcUUID

    Notes:

    */

    DEFINE OUTPUT PARAMETER pcUUID AS CHARACTER

    NO-UNDO.

    pcUUID = GUID( GENERATE-UUID ).

    END PROCEDURE .

    No this is not pre-10.1A. It uses the new 10.1A language features to generate a global UUID.

  • Got it. Thanks.

    What about the "If we had it to do over again" aspect?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • My point is that with 10.1A this becomes trivial and a language built-in so I was guessing that the procedure preceded 10.1A and originally contained some workaround code to imitate what the built-in now does. Then, when you got the built-in, it replaced the body of the procedure.

    Nothing significant. This is exactly the way I like to code when I expect something to be coming down the line so that minimal changes are necessary to switch over. I was just amused by how trivial the procedure became.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Personally, I would always wrap a GUUID() in a function or procedure all - that way if there's anything else that needs to be done at the same time the ID is obtained, it can be.

  • OK, I've been through the standards doc. My compliments that one actually exists and even seems to have been followed. I was originally thinking to have some give and take here, although I was first hoping to get the AutoEdge folks to make some comments on what they might decide to do differently, but it seems to me that the initial response might be a bit lengthy. What about the idea of converting it to a PDF and then I could add annotations and post both versions on OE Hive? I think that would be interesting.

    There is a lot of it that is minor questions of taste, but a few points which I think are more substantive and "chewy", i.e., actually worth discussion.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Got it. Thanks.

    What about the "If we had it to do over again" aspect?

    We're tried to address some of the 'If we had to..' in the 'Lessons Learned' sections in the supporting sample documentation which can be found in each of the OERA sub-categories under the AutoEdge category (http://www.psdn.com/library/kbcategory.jspa?categoryID=298).

  • This is not in the download materials?

    I'm not readily finding it at that link?

    While I am interested in the question generally, this specific one was about the standards.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com