There are a few quite different mindsets of DriveWorks implementers that you’ll find in the DriveWorks community. The primary difference between them lies in their views on the subject of structure. Some people build huge, monolithic projects with everything in one place. These people typically come from a Microsoft Excel background, where worksheets are there for when you run out of space. Some people come from an object-oriented programming background. These folks look at a project as a container that stores very specific information about a very specific part of the process and has the tools to execute the tasks that part of the product would need to perform. Still others come from a database background and they look at DriveWorks as a tool to generate information to be stored elsewhere (typically, a large number of SQL tables) and to be presented to the user as required for them to complete their daily jobs.

Now, while there are no wrong answers in DriveWorks architectural design, there are some that are, well, let’s just say “less right” than others. And sorry, monolith builders, but you’re it. Large projects may make it easier to develop your implementation because you don’t need to pass information or switch between projects, but the benefits pretty much stop there. Larger projects are often subject to performance issues, can be more challenging to maintain and are typically not very flexible or scalable. The idea of compartmentalizing your DriveWorks implementation into components, or items, or objects, is to allow you to reuse these components as needed. Reuse means that you only need to write rules once. Separating components means that the queries, calculations and loading of things like tables will only be performed when it’s necessary. And by building these smaller building blocks, they can be combined into a larger number and wider variety of finished products, all with a consistent look, feel and function.

Let’s take a look at a few tools that DriveWorks has provided that support this concept of the modular implementation.

The primary trait that these tools share is the ability to be called time and again, on an as needed basis. While this typically means that our component is a project, the exception to this is when we use a form as a reusable block. Form navigation typically provides a very linear (with a few branches) approach to interacting with our users. The Skip To Form specification macro, however, allows us to jump to any point in our form navigation. Note, though, that this means that our target form must lie within the navigation path. The alternative to this is a free floating, or dialog, form.

In DriveWorks terminology, a dialog form is simply a form that lies outside of the form navigation flow. It still shows in the form navigation screen, but there are no lines connecting it into the other forms in the flow. Dialog forms can be called in a variety of ways. The most popular used to be the Dialog Button which brings the form to the front and stops the implementation until that form is addressed and closed. This has been replaced in popularity by the Frame Control which allows us to display a form within a control on another form. In this way, we can have a header that is consistent across our screens, a summary box with live pricing, or collapsible sections within our form. With a frame, a single form can be reused for multiple purposes at many points throughout the specification process. Frames are controls. And like every other control, they have properties. This means that their sizes, location, visibility and enabled state can all be rules-driven.

There is a third, somewhat lesser known, method for calling dialog forms, and that is the Item List. An item list will allow you to present one of any of your dialog forms every time the user clicks Add, and will automatically store the information from the dialog form into a table. The Item List is often compared to a child specification which launches a dialog instead of another project.

And the Child Specification is certainly the most popular method for people to compartmentalize their implementations. What’s great about the child specification and item list are that the user can click Add as many times as they want, and you don’t have to have a large number of controls or instances of master models or external data storage to handle it. Child specifications are now, by default, embedded within the parent specification, so these building blocks are invisible to your users. The child specification control and the dialog button and the item list all have one drawback, though, that being the fact that the dialog form or child specification is brought front and center and must be attended to before the user can move forward with anything else. In most cases, the original specification forms are covered up, so that the user can’t even see them.

The newest addition to the modular arsenal addresses this. The Specification Host control is like a frame control that displays specifications instead of forms. These specifications can be child specifications, or they could be new specifications created on the fly, or they could be existing specifications being reopened through their own specification flow. Specification host controls, along with frame controls, allow you to present interfaces seamlessly to the user. These are not dialogs, they are simply areas within your form that your users don’t know are separate areas. As a result, using these two tools allows you to create very cohesive, single page applications that are really made up of not only multiple forms, but even multiple projects, in many cases.

So start to take the time to look at your implementation and ask the following questions:

• Are there any queries, lookups or calculations that I want to only run when I need them to save time?
• Are there any controls that I’m duplicating from form to form that I could really just be reusing?
• What could I take out of my project to be a standalone component that would be reusable by other projects within my group?

And once you head down the road of compartmentalizing and modularizing your implementation, I think that you will find new levels of flexibility, performance and scalability. Yeah, I really do think.

The post Modularizing Your DriveWorks Implementations appeared first on Razorleaf.