BOL objects and naming conventions

    Well, the problem lay in  the fact that I had used an identical name(Item) for a particular BOL object within my model. This was due to the impression that since I had used a Z-name space for my model(component and component set), I was free to name objects within it as I chose. I was satisfied with the fact that the object name was unique within the sales model(BT & ONEORDER). Obviously, that was not enough. When the user session is created, the BOL models are loaded when the users access various work centers and the models, once initialized, stay put for the rest of the session. When the model is loaded, the BOL object information is loaded and the objects are not, as one might think, protected within their respective component sets. It is the objects themselves which make up the BOL environment, meaning that they act like a “key” in the BOL environment. The component and component set are not part of this “Key”. My problem was that the users had access to both sales and survey work centers. Irrespective of which component is loaded first, the next would end up in error as the BOL object name is supposed to be unique in the BOL environment. If you are interested, only the object name and object id(the table key) act as the key to the business entities. When the business entities need processing, the model is decided based on the object name and the respective implementation class will be called. In my case, the system wouldn’t know which model to call. So, it will simply not allow same object names even though they belong to different models.

  Now, what was I to do? These are exactly the times when you wish you had followed the “good” programming practices. Throughout the BOL implementation class, the names were hard coded. This time, I decided to do better. I started with the tables in which I had maintained the model information and changed the names. The implementation classes were next. This was the hardest part as I had to go through literally each and every method changing the hard coded values. The next were the BSP components using the models. Fortunately, I was fully involved in all the developments and I knew the places where the names were used. These were only a few, where we created the root object or called the search object. The next were of course the model nodes. I had to visit all the component, custom, window and view controllers and change the values in the attribute BASE_ENTITY in all the models. Though it was tedious, I didn’t mind. I had learned one more “what not to do”! So, here I’m again working on another model and this time you can bet there will be a Z leading all my object names!