Topic group Related topics

Dynamic External Objects is a unique technology that allows not just users, but applications, to share classes across a network (and soon, across the Web). Instead of linking your forms, programs, classes and reports into a single executable that has to be manually installed on each workstation, you deploy a shell - a simple dBASE Plus executable that calls an initial form, or provides a starting menu from which you can access your forms and other dBASE Plus objects. The shell executable can be as simple a program as:

   do startup.prg

where "startup.prg" can be a different ".pro" object in each directory from which you launch the application, or a program that builds a dynamic, context-sensitive menu on-the-fly.

Dynamic Objects can be visual, or they can be classes containing just "business rules", that process and post transactions, or save and retrieve data. Each of these objects may be shared across your network by all users, and all applications that call them.

For example, you may have a customer form that's used in your Customer Tracking application, but may also be used by your Contact Management program as well as your Accounts Receivable module. Assume you want to change a few fields on the form or add a verification or calculation routine. No problem, just compile the new form and use the Windows Explorer to drag it to the appropriate folder on your server. Every user and application is updated immediately.

Benefits of using Dynamic External Objects:

Updating objects requires only a simple drag-and-drop. No registration, no interface files, no Application Server required. Updating has never before been this easy.

Although the objects sit on your network server, they run on the workstation, reducing the load on the Server dramatically and making efficient use of all that local processing power sitting out on your network.  

The same (non-visual) objects may be shared by both your LAN and your Web site. Dynamic External Objects are very small and load incredibly fast. They rarely exceed 140K in size and usually run less than 100K.

And, most remarkable of all, this is one of the only Object Models that supports full inheritance. You can't inherit from an ActiveX/OCX object. You can inherit Java objects in CORBA, but it's so difficult it's rarely attempted. With dBASE Plus, inheriting External Objects is a piece of cake:

Change the layout of a superclass form and every form in every application inherits those changes the next time they're called.

Renamed your company? Changed your logo? Drag and drop the new .cfo file to the Server and the update is finished.

Implementing Dynamic Objects

Done !

Like Source Aliasing, DEO has a mechanism for finding libraries of objects, making it much easier to share them across the network and across applications. This mechanism is based on an optional search list that's created using easy text changes in your application's .ini file.

dBASE Plus searches objects as follows:

  1. It looks in the "home" folder from which the application was launched.  

  2. It looks in the .ini file to see if there's a series of search paths specified. It checks all the paths in the list looking for the object file requested by the application.  

  3. It looks inside the application's .exe file, the way Visual dBASE did in the past.  

Let's assume you have a library in which you plan to store your shared objects. Let's also assume the application is called "Myprog.exe" and runs from the c:\project1 folder.

In Myprog.ini, we might add the following statements:

  [ObjectPath]

  objPath0=f:\mainlib

  objPath1=h:\project1\images

  objPath2=f:\myWeb

Your code looks something like the following:

  set procedure to postingLib.cc additive

dBASE Plus will first look in c:\project1 (the home directory).

If that fails, dBASE Plus will look in f:\mainlib. If it finds postingLib.co, it will load that version. If not, it looks in each of the remaining paths on the list until it finds a copy of the object file.

If that fails, dBASE Plus will look inside MyProg.exe.

Tips

You'll have to experiment with DEO to discover the best approach for the way you write and deploy applications. However, here are some interesting subtleties you might leverage to your benefit:

Unanticipated updates: Assume you already shipped a dBASE Plus application as a full-blown executable. Now you want to make a change to one module. No problem, just copy the object file to the home directory of the application and it'll be used instead of the one built in to the executable. You don't need to redeploy the full application the way you do in most other application development products. Just the changed object.

Reports: You can deploy reports or even let your users create reports (using dQuery) and add them to their applications by designing a report menu that checks the disk for files with an .reo extension. Let the menu build itself from the file list. Here we have true dynamic objects - the application doesn't even know they exist until runtime. DEO supports real-time dynamic applications.

Tech Support: Want to try out some code or deploy a fix to a customer site or a remote branch office? No problem, just FTP the object file to the remote server and the update is complete.

Remote Applications: If you have VPN support (or any method of mapping an Internet connection to a drive letter), you can run dBASE Plus DEO applications remotely over the Internet. A future version of dBASE Plus will include resolution of URLs and IP addresses so you can access remote objects directly through TCP/IP without middleware support.

Distributed Objects: Objects can be in a single folder on your server, in various folders around your network, or duplicated in up to ten folders for fail-over. If one of your servers is down, and an object is unavailable, dBASE Plus will search the next locations on the list until it finds one it can load. Objects can be located anywhere they can be found by the workstation.