The Problem with Embeds, Revisited
In 2009 I wrote a five part series in Clarion Magazine on what I think is a massive problem facing Clarion developers: the abuse of embed points.
I argued that the code that gives your applications their value isn't the code that Clarion writes for you; Clarion's job is to do the grunt work so you can write the really valuable code, the stuff for which your customers shell out their hard-earned.
Only the vast majority of us put that code in the worst possible place: embed points.
Code in embed points is all too often difficult to understand, debug and maintain. It's awkward to test and generally non-reusable.
The three intervening years haven't mellowed my opinion; if anything I've become more rabid about the need to deal with the horrors of embed code, and more convinced that abuse of embed points is the single most critical problem in Clarion development!
The short answer: get that code out of embeds and into classes! But there are a lot of twists and turns on that road so I'm revisiting and updating the series in September and October.
This series is also a great way to begin familiarizing yourself with the DevRoadmaps Clarion Library, our new GitHub-based repository of reusable Clarion code!
- The Problem with Embeds, Part 1: What Went Wrong?
- The Problem with Embeds, Part 2: Refactoring the TXA Parser
- The Problem with Embeds, Part 3: Testing the TXA Parser
- The Problem with Embeds, Part 4: A TXA Embed Viewer
- The Problem with Embeds, Part 5: The Invoice App
- The Problem With Embeds, Part 6: The CalcValues Code
- The Problem With Embeds, Part 7: Unit Testing The InvoiceDetail Class