When UNIX V was with MF Cobol the world changed for us.
Based on the frequent changes in the text , language , legal and other requirements , we never had a wording = text in the source.
we had :
01 Field1xxxxx ( element of the Data Dictionary ) .
02 Subfield Pic x(80).
At the moment the text was necessary what wording so ever it was called from a data base and moved into the Subfield by adjusted length.
What kind and size of text was necessary a key indicated. All text was stored in a text data base and each one had its own key. A browser helped finding the text and the key. This key was randomly inserted in the filekey of the source.
This technology avoided any dependency of source change regarding the text.
Heinz
Posts
Hey Heinz, Good point! Your approach is practical in other languages as well.
ReplyDeleteWhen building any application which presents text to a user, I agree it is a good practice to define a placeholder for the text and then during program execution load the text into the placeholder.
I've recently been working with building graphical interfaces and this approach will work very well there too.
Thanks for the tip!
This is yet another example of the importance of separating view from model. The text should be part of the model and the view simply says how to display it. In a multi-locale application one frequently arrives at having two models. There is the text model which holds the locale specific versions of text and the application model, which holds the data and information upon which the program operates. One can see this as a MMVC (model model view controller) approach.
ReplyDeleteIt is an interesting hyper-contextual thought that one of the greatest challenges in dealing with legacy code (see the other conversations going off on this blog) is that the model, view and controller tend not to be separated in a log of programs. COBOL ADIS or VB6 forms both tended to result in programs where the model was a mixed with the controller and the whole lot coded into the view.
A rigorous approach to formal analysis and separation of these elements is a key requirement for modernizing (and hence increasing the life span of) legacy code. Where legacy code has followed strong coding conventions as described in this post, the challenge of modernization is massively reduced.
- AJ