FoxQuill another VFP Framework
FoxQuill is my homegrown framework I am working with amongst others. Within the next months (from March, 2014 on) I will expose some very interesting insights here. Starting with some challenging FoxQuill Base Classes I will show you the whys and wherefores of my design. Be warned, this will not be a VFP beginner's lecture but I'm afraid, there won't be much of them still out there today…
Table of Content
FoxQuill an Overview
This is a short introduction of what we are going to talk about in this section of my blog. This is no "all about another VFP framework" but what is so special about the FoxQuill framework and why I decided to do it just that way.
Core Components
I will overview the Core Components of FoxQuill which will be discussed in detail in my upcoming posts. You will find a lot of them being helpful examples for the statements I posted a long time ago (22 OOP Design Rules).
The Factory
FoxQuill is a data-driven framework, so is the The Factory component! The Factory belongs to FoxQuill's Core Components ensuring highest flexibility in object creation even at runtime!
The GPStore
Data-driving an application, or an application framework, needs a lot of tables! The General Purpose Store belongs to FoxQuill's Core Components simplifying the handling of meta data used by all other Core Components like the Factory, the Workflow, and the Matrix, just to name a few of them. The GPStore radically simplifies data handling of application related (meta-)data!
The Construct
Object-Pooling is nothing new. FoxQuill's Object-Manager called The Construct raises application-internal object hosting and maintenance to the next level. With the aid of The Construct developers are able to change any application aspect dynamically (even at runtime!) without re-coding!
The Matrix
FoxQuill supports dynamic, table-driven object creation and composition at runtime. Thus, FoxQuill has to support dynamic messaging, too! FoxQuill's Unified Object Messaging system is called The Matrix which enables the developer to control any aspect of object collaboration even at runtime!
The Workflow
FoxQuill supports dynamic, table-driven behavior not only at the class-instance level but also at the application level. "Hot gluing" all framework components together at runtime and controlling them is the business of The Workflow engine. Naturally, the Workflow also is completely table-driven and supports the concept of task-oriented application design.
The Kernel
Bringing all Core Components together is realized by The Kernel. The Kernel component also is called the FoxQuill Core. It can be compared to an electric control cabinet in the real world, or the program kernel of UNIX operating systems. The re-using developer will not change any Kernel aspect programmatically, but through simple table-based configuration, if at all. Compiling the Kernel into an VFP App/Exe, then starting it, will lead to some kind of application hosting service running. This App-Host Instance can then be commanded to load and execute any kind of further APPs/EXEs that were build upon FoxQuill's Base Classes.
Libraries & Tools
All of the above things are build upon a rock-solid bunch of framework classes called The FoxQuill Libs. Nobody should feel forced to use them but may stay with the own set of base classes. As I said before, this blog is no advertisement that wants to lead you to buy my system. Quite the contrary, it would be more satisfying if it would lead you to re-think and re-work your own classes. The FoxQuill Libs went a long way through everlasting refactoring. At the moment they will be refactored a last time to become My Final VFP Version. The classes in the final FoxQuill Libs will be ready to be migrated to other languages pretty easily (using special tools for that job).
FoxQuill will become FoxQuill.NET
Some thoughts and insights dealing with my VFP framework (
I'm so happy you're going to continue this blog item! I've been waiting and hoping you would continue. Keep up the good work!
ReplyDeleteHi Burkhard, I stumbled on your blog. Very interesting concept. I like to read more on this and other insights. Is there still any continuation? I hope so.
DeleteHi Burkhard. I stumbled on your blog. Very interesting stuff and insights. I would like to read more about it. Is this project still continuing? I hope so. Would be very nice :)
Delete@TRH: Thank you for your supporting comment! And, YES, I do continue this blog item! At the moment I'm busily refactoring parts of the FoxQuill Kernel. I' also adding new functionality to the GPStore - I'm trying to make it a fully functional Object-Database(!). I hope this will be the final VFP version, then :-)
ReplyDeleteExcellent! Your blog is one of the ones I just leave open in a tab for weeks, it really is the best vfp resource for the intimate details of FoxPro.
DeleteI'm very much looking forward to your customizations to the _foxcode table that you alluded to in an earlier post. I can find no good resources on truly customizing it the way I want...
Can't wait!
@TRH: Nice to hear that from you! Alas, I'm afraid I didn't remember that I've ever talked about "_foxcode.dbf" in any of my posts! Or, did you mean "_foxuser.dbf"? I have some interesting things to tell about some of the Debugger-related entries made in _foxuser.dbf and other undocumented record-types but I haven't found any noticeable (intimate:-) things about the (mis-)use of _foxcode.dbf because I didn't touched it for a while. I'm running my own Intellisense support based on the My-Class included in the Sedna-files...
ReplyDeleteLet me know the post you are referring to!
@THR: Sorry, I meant "FoxUser.dbf" and "FoxCode.dbf" without the leading underscore.
ReplyDelete@THR: Yes, you're right. Now I remember what you were talking about. Well, implementing custom Intellisense behavior is no rocket-science, although, it's pretty weird. I recommend studying THOR sources; one can find a lot of intellisense stuff under ThorTools -> Code ->IntellisensX...
ReplyDelete