Olaf Doschke
Programmer
Hello all,
just a short hint on the Newobject function. The documentation about it bugged me a bit, it says_
What do you mean "and so on"?
The givens are quite broad possibilities and I think nobody really cares much, as you can always put a class into a prg or vcx and that's where they belong anyway. Some base classes can only be subclasesed in a PRG ('Session', for example).
What about another very valuable location of classes you can share with the users of your app? Something you can provide without updating the installation (well, aside from the fact that new classes usually also need new code to use them, but think about updates of existing classes).
I thought of trying a DBC as cModule, but that fails, And cInApplication is even just for specifying an EXE or APP that contains the VCX or PRG or other file cModule specifies.
Still, this brought me to a very simple way of providing a class in a DBC, that not necessarily is only meant to be used by the DBC stored procs. It might provide a feature for your DBC but also for other external extensions, just like a DBC is a natural place for remote views to actually use a remote database it could be the headquarter to other external and remote things that root in a VFP class definition. For example, a class using a REST API. In the end, you use this within the VFP EXE process and can also add it there in a VCX, but why not go other routes, too?
And here's the point, that may even be a disappointment and you already use this all the time, but it just occurred to me as not just a hack but a natural way to locate some things, especially data access related:
Yes, that's all folks. And to be very clear it doesn't add DBC as a possible class location for the NEWOBJECT function, but for VFP at all. Just a language extension made available by having a DBC open. And if you're normal in first spotting the quote and code sections of a post you may never even read all this anyway and still get it: If you put this into the stored procs of a DBC you can instance classes defined inside it also outside of the DBC. Obviously, that also needs class definitions in the DBC and it's limited to PRG classes (DEFINE CLASS) and it also should be class definitions relevant to being located there, ie for being used within the DBC, but it's not just limited to that.
Just think about how that enables switching between DBCs with other implementations of the same family of classes with the same names or other ways of making use of it. And it's in one central place that a LAN application makes use of. Even when you already migrated all your data to server backends and not use remote views, you'll still know how your application can easily let all users see a DBC in a file share. And now it can become a repository of a library of functionality.
A con is obviously that instancing a class reaches into the LAN, but the instance itself is just an integral part of the client process as any other class instance coming from a VCX or PRG compiled into the EXE.
And yes, there are other ways of just putting FXPa or PRGa or VCXes into a file share without a DBC, so a reason should perhaps be, that the classes are related to the DBC itself, ie classes the stored procs within the DBC use. They won't need the dbcObject function itself to make the class definition accessible, as you can always use CREATEOBJECT() to find classes defined in the current code context. But maybe it already helps to realize that you can actually make use of OOP within a DBC stored proc and write OOP style referential integrity or audit trail code, for example. The stored procs don't limit you to procedural programming style within DBC routines. And it might also make available data access objects like cursor adapters that, well, are up to date with the current DBC table structures, just to name one possible idea of a sensible usage of this contained in a DBC and not the updated version of your EXE.
Bye, Olaf.
Olaf Doschke Software Engineering
just a short hint on the Newobject function. The documentation about it bugged me a bit, it says_
vfp help said:
What do you mean "and so on"?
The givens are quite broad possibilities and I think nobody really cares much, as you can always put a class into a prg or vcx and that's where they belong anyway. Some base classes can only be subclasesed in a PRG ('Session', for example).
What about another very valuable location of classes you can share with the users of your app? Something you can provide without updating the installation (well, aside from the fact that new classes usually also need new code to use them, but think about updates of existing classes).
I thought of trying a DBC as cModule, but that fails, And cInApplication is even just for specifying an EXE or APP that contains the VCX or PRG or other file cModule specifies.
Still, this brought me to a very simple way of providing a class in a DBC, that not necessarily is only meant to be used by the DBC stored procs. It might provide a feature for your DBC but also for other external extensions, just like a DBC is a natural place for remote views to actually use a remote database it could be the headquarter to other external and remote things that root in a VFP class definition. For example, a class using a REST API. In the end, you use this within the VFP EXE process and can also add it there in a VCX, but why not go other routes, too?
And here's the point, that may even be a disappointment and you already use this all the time, but it just occurred to me as not just a hack but a natural way to locate some things, especially data access related:
Code:
Procedure dbcObject(tcClass)
Return CreateObject(m.tcClass)
EndprocYes, that's all folks. And to be very clear it doesn't add DBC as a possible class location for the NEWOBJECT function, but for VFP at all. Just a language extension made available by having a DBC open. And if you're normal in first spotting the quote and code sections of a post you may never even read all this anyway and still get it: If you put this into the stored procs of a DBC you can instance classes defined inside it also outside of the DBC. Obviously, that also needs class definitions in the DBC and it's limited to PRG classes (DEFINE CLASS) and it also should be class definitions relevant to being located there, ie for being used within the DBC, but it's not just limited to that.
Just think about how that enables switching between DBCs with other implementations of the same family of classes with the same names or other ways of making use of it. And it's in one central place that a LAN application makes use of. Even when you already migrated all your data to server backends and not use remote views, you'll still know how your application can easily let all users see a DBC in a file share. And now it can become a repository of a library of functionality.
A con is obviously that instancing a class reaches into the LAN, but the instance itself is just an integral part of the client process as any other class instance coming from a VCX or PRG compiled into the EXE.
And yes, there are other ways of just putting FXPa or PRGa or VCXes into a file share without a DBC, so a reason should perhaps be, that the classes are related to the DBC itself, ie classes the stored procs within the DBC use. They won't need the dbcObject function itself to make the class definition accessible, as you can always use CREATEOBJECT() to find classes defined in the current code context. But maybe it already helps to realize that you can actually make use of OOP within a DBC stored proc and write OOP style referential integrity or audit trail code, for example. The stored procs don't limit you to procedural programming style within DBC routines. And it might also make available data access objects like cursor adapters that, well, are up to date with the current DBC table structures, just to name one possible idea of a sensible usage of this contained in a DBC and not the updated version of your EXE.
Bye, Olaf.
Olaf Doschke Software Engineering
