Now that we understand workspaces and targets, we can start to get a feel for what type of infrastructure we want to use for our application.

As I mentioned in my last column (PBDJ, Vol. 12, issue 7), we need to answer some questions regarding standards and frameworks.

As Larry wrote about in last month's column (PBDJ, Vol. 12, issue 8), we also have to choose whether to include multiple applications in a single workspace, have a workspace contain one application, or perhaps have a workspace contain all applications related to a specific business area. Once those issues are resolved, we can start to think about our application design in terms of objects, user interface artifacts, database access, transaction management, and other items that are the meat of our infrastructure.

Contrary to the Borg's mantra of "Resistance is futile" in Star Trek, you should resist the temptation to just jump in and begin coding. You'll quickly find, no matter the size of the project, that some design goes a long way toward allowing you to be more productive more quickly. Think of it as pseudo-coding a difficult piece of logic. The pseudo-coding may seem like a waste of time - time that could have been spent on the actual coding. But, in reality, the exercise of pseudo-coding often points out that we had invalid assumptions, poor logic flows, or a convoluted and difficult design. The time we spend on the pseudo-coding should pay us back handsomely in terms of a sleeker, more complete piece of coding. Similarly, the time we spend answering design and infrastructure questions up front will provide us with a better foundation when we get down to actually building our application.

So, let's ask, discuss, and answer some questions.

What Is the Name of Our Application?
Seems pretty basic, huh? But, the truth is, this little piece of information forms the basis of our naming standards. If our application is named MarketTrader, our w_customer, for example, might be better named, w_markettrader_customer. Our w_account might be better named w_markettrader_account. Our base DataStore object might be better named n_markettrader_ds instead of n_ds. If MarketTrader seems a bit verbose, we could shorten the mnemonic to "mt" to yield w_mt_customer, w_mt_account, and n_mt_ds.

For this column, the application is "pbdj_CS", so we will use "cs" as the basis of our naming standards. This means that window names will begin with w_cs, nvos will begin with n_cst_cs, menus will begin with m_cs, and so on.

Do I Really Need to Prefix Each Object with a Mnemonic?
The short answer is "Yes." There are a couple of reasons for doing this. Prefixing an object with the application mnemonic allows you to recognize to which application this object belongs. If your workspace has multiple applications and they each have a w_about window, it can sometimes be confusing which w_about you are currently editing or where you are going to be saving it. Another reason for doing this is if you are using a framework that already provides a default implementation of w_about. For example, if you were using PFC, you would recognize that w_about exists in the PFE layer as the extension of the pfc_w_about. Best practices are to inherit from w_about to create your own application-specific version of the about box - in our case, w_cs_about.

Another mnemonic you may need to consider is to incorporate the application subsystem within your naming standard. This applies in cases where the same basic name could be used in multiple places within your application. For example, in our MarketTrader application, we may have both an equity trading window and a fixed income trading window. If we had only one, we would be inclined to name it w_mt_tradeentry. However, with the need for two trading windows (and the possibility later of adding ones for derivatives, precious metals, bank notes, etc....), we should probably incorporate the subsystem into the name. This might lead us to name our trade entry windows as w_mt_eq_tradeentry, w_mt_fi_tradeentry, w_mt_dv_tradeentry, etc....

Reviewing our choices for how we want to configure our workspaces and targets has a reasonable amount of influence as well. In our last scenario, if we had decided to have the MarketTrader application in its own workspace, we might choose to exclude the "mt" mnemonic altogether (except where absolutely necessary - like our w_about case above). Our trade entry window names would then become, more simply, w_eq_tradeentry, w_fi_tradeentry, and w_dv_tradeentry.

My personal preference is to have separate workspaces for each business area. In each workspace, I place all applications related to that business area. This would allow me to use the convention of w_eq_tradeentry instead of w_mt_eq_tradeentry in our MarketTrader application.

Do I Want or Need to Use a Framework?
If you're building an application that will not utilize at least 50% of a framework, it may not be necessary to use one. In effect you are carrying the weight of the entire framework for a small return. If portions of the framework can be decoupled from the whole, then the decision becomes much easier...just utilize those pieces of the framework that you need to use.

If I Don't Need Framework, I Can Get Started, Right?
Even if you choose to not use a framework, there are a number of "base" objects that you absolutely should create for use in your application. In fact, these objects can be placed in a library and reused across multiple projects (see sidebar for a discussion of sharing .pbls across multiple projects). These objects include ancestor objects of type window, MDI sheet (main), transaction, DataStore, and DataWindow and may also include response window, about window, command button, menu, and appmanager.

The reason for this is simple: it allows for flexibility and extensibility in your application. It is much, much, much simpler to change or provide new functionality in one ancestor than it is in 20 descendant objects.

For example, if you wanted every window to have the application icon associated with the window, do this at the base ancestor window level. The icon property will be inherited to all other windows. If you decide to change the application icon and, consequently, the icon at the window, you have to modify only one object. The icon attribute can always be overridden at a descendant level if the need arises. Let's say you have the following window class structure:

w_base
   w_sheet
     w_customer
       w_eq_customer
       w_fi_customer
       w_pm_customer
     w_account
       w_eq_account
       w_fi_account
       w_pm_account
     w_tradeentry
       w_eq_tradeentry
       w_fi_tradeentry
       w_pm_tradeentry

Set the icon property of w_base to be the same .ico file as is associated with the application object. If you decide later in the project development cycle that the customer windows should have an icon specific to customer and the account windows should have an icon specific to account, then you make two changes - in w_customer and w_account - not six changes.