Skip Rewriting the Same Code — Standard Code, Abstraction, and a Root Interface (1 Viewer)

[GPGeorge]

The video from Eric Blomquist's April 2nd presentation of his Access Root Interface and Object Superclass Framework for the Pacific chapter of Access User Groups is now available on YouTube.
Links to articles further describing them are in the video description.

Eric Blomquist walked us through a demo and illustration of the development structure he uses to share code across forms and across applications.

His framework is built on a comprehensive set of superclasses that leverage a core foundation which he calls a Root Interface.

The core idea: a naming convention rigorous enough that code can identify any object by entity and type at runtime — which means objects can be passed as parameters and code can act on them without knowing in advance which specific form or control it’s dealing with. Layer in consistent design patterns for common form functions, and you have a root interface: not a formal documented structure, but a reliable contract that your code can be written against.It all comes to live in a Framework of standard code, made up classes and superclasses.

Want to learn more about Eric's Root Interface and Framework? Here are links to the foundational articles on Reddit.

Foundations - An Access Root Interface

Frameworks: An Object Superclass Framework
Additional download files for Eric's presentation and PDFs of the two articles, are available at our AUG chapter website, where you can also sign up to be notified of future meetings.

https://accessusergroups.org/groups/pacific/

 

[The_Doc_Man]

I did not view the presentation, but I recognize something here.

The core idea: a naming convention rigorous enough that code can identify any object by entity and type at runtime — which means objects can be passed as parameters and code can act on them without knowing in advance which specific form or control it’s dealing with. Layer in consistent design patterns for common form functions, and you have a root interface: not a formal documented structure, but a reliable contract that your code can be written against.It all comes to live in a Framework of standard code, made up classes and superclasses.

Any of you familiar with the product called PeopleSoft will recognize a similar concept to the description of that core idea. It is a common enough topic that we have occasional "hits" on the subject of data-driven applications - things that handle a lot of management bookkeeping just by knowing what it is that you are managing.

A practical strength for such products is that if you have classes built up for the most common objects, a lot of functions can be defined that are either completely or at least mostly handled within the classes. Putting together special details to form a coherent app becomes a lot easier since you have a lot of the work already done.

A weakness for such products is that if you have a LOT of objects eligible to be treated as members of a class, but you don't have classes for EVERY such object, you run into implementation difficulties. Either you need to do a lot of catch-up programming (that is rarely inexpensive) OR your magnum opus becomes a tail that wags the dog (which customers really don't like).

For anyone who wants to see some news articles about this weakness and what it does to projects, look up DIMHRS, which has multiple articles in news articles, including a Wikipedia history. It is a perfect example of starting a project with an inadequate set of object classes and the need for a LOT of expensive retrofitting.

 

[GPGeorge]

I did not view the presentation, but I recognize something here.


Any of you familiar with the product called PeopleSoft will recognize a similar concept to the description of that core idea. It is a common enough topic that we have occasional "hits" on the subject of data-driven applications - things that handle a lot of management bookkeeping just by knowing what it is that you are managing.

A practical strength for such products is that if you have classes built up for the most common objects, a lot of functions can be defined that are either completely or at least mostly handled within the classes. Putting together special details to form a coherent app becomes a lot easier since you have a lot of the work already done.

A weakness for such products is that if you have a LOT of objects eligible to be treated as members of a class, but you don't have classes for EVERY such object, you run into implementation difficulties. Either you need to do a lot of catch-up programming (that is rarely inexpensive) OR your magnum opus becomes a tail that wags the dog (which customers really don't like).

For anyone who wants to see some news articles about this weakness and what it does to projects, look up DIMHRS, which has multiple articles in news articles, including a Wikipedia history. It is a perfect example of starting a project with an inadequate set of object classes and the need for a LOT of expensive retrofitting.

Interesting alternative viewpoint. I wish you'd had the opportunity to participate in the after-presentation discussion.

 

[RonPaii]

I watch the presentation video. Is there a 2nd one for the discussion or just refence the Reddit post?

 

[GPGeorge]

Hi Ron. Thanks for asking. This was a pilot test for a format we're experimenting with for YouTube videos.
Our goal is a video ~15 minutes long. The remainder of the discussion-- another hour and a half, was not recorded.
Would you like to hear more about the concept of a Superclass Framework?

 

[RonPaii]

The video looks interesting, I would like to have attended but spent 12 hours moving on the 2nd. The discussion would likely be informative.

I have implemented similar concepts like my menu system. Each form passes a Combo box or List box control and form ID to a function that fills the record set with the menu options or hides the control if no menu options. Makes for a very flexible and effective menu, presenting only options the user has rights for.

 

[NauticalGent]

Would you like to hear more about the concept of a Superclass Framework?

 

[GPGeorge]

I will ask Eric back to further explain the framework.

 

[tvanstiphout]

I did not view the presentation, but I recognize something here.


Any of you familiar with the product called PeopleSoft will recognize a similar concept to the description of that core idea. It is a common enough topic that we have occasional "hits" on the subject of data-driven applications - things that handle a lot of management bookkeeping just by knowing what it is that you are managing.

A practical strength for such products is that if you have classes built up for the most common objects, a lot of functions can be defined that are either completely or at least mostly handled within the classes. Putting together special details to form a coherent app becomes a lot easier since you have a lot of the work already done.

A weakness for such products is that if you have a LOT of objects eligible to be treated as members of a class, but you don't have classes for EVERY such object, you run into implementation difficulties. Either you need to do a lot of catch-up programming (that is rarely inexpensive) OR your magnum opus becomes a tail that wags the dog (which customers really don't like).

For anyone who wants to see some news articles about this weakness and what it does to projects, look up DIMHRS, which has multiple articles in news articles, including a Wikipedia history. It is a perfect example of starting a project with an inadequate set of object classes and the need for a LOT of expensive retrofitting.

His framework has very little if anything to do with "data-driven applications".

 

[The_Doc_Man]

His framework has very little if anything to do with "data-driven applications".

Technically, because of the Component Object Model issues, Access itself is data-driven. The data in question comes from the members of the various collections such as tables, queries, forms, etc. In fact, since the VBA compilation is a pseudo-compilation, even VBA is data-driven.

 

[Gasman]

TBH it reminded me of Visual FoxExpress.
That would use many functions for quite a simple task, but you could reuse the framework over and over again.
Took quite a while to learn, just as Access is to start with.
If you have not created this framework ahead of time (lot of work) then you need to purchase such a framework and then learn to use it?
I mentioned in another thread, to not hard code and make the logic data driven. A little more work upfront for no code changes.
This seems to be a lot of work up front, and you get to make that effort worthwhile.

 

[KitaYama]

I have implemented similar concepts like my menu system. Each form passes a Combo box or List box control and form ID to a function that fills the record set with the menu options or hides the control if no menu options. Makes for a very flexible and effective menu, presenting only options the user has rights for.

Is it possible to upload a database that shows this concept? (if it's not commercial).
I read your other post about your menu, but still have some difficulties to digest how it works. A sample database may clear the cloud.
If you prefer not to, it's OK too.
Thanks.

 

[RonPaii]

Is it possible to upload a database that shows this concept? (if it's not commercial).
I read your other post about your menu, but still have some difficulties to digest how it works. A sample database may clear the cloud.
If you prefer not to, it's OK too.
Thanks.

I will workup a sample database with the menu.

 

[RonPaii]

I will workup a sample database with the menu.

I posted a sample Database.

https://www.access-programmers.co.uk/forums/threads/menu-system.335354/

 

[Gasman]

I posted a sample Database.

https://www.access-programmers.co.uk/forums/threads/menu-system.335354/

Link does not work?

 

[RonPaii]

Link does not work?

It's under review

 

[NauticalGent]

I posted a sample Database.

https://www.access-programmers.co.uk/forums/threads/menu-system.335354/

It helps if you "report" your own post so the Mods get an alert...

 

[riktek]

Eric here. George just told me about the interest here. I'm available here for questions and comments, and may re-post the two Reddit papers here for reference. The character limits of AWF weren't sufficient, which is why they ended up on Reddit for the first go.

 

[tvanstiphout]

@eric: As a side show, I've learned that the Implements keyword only implements an interface for methods and properties, NOT for events. Sometimes a class object may want to inform its "subscribers" that some custom event has happened. Along the same way as "observable collections" in C#. Have you run into this dilemma, and if so, how did you work around it?

 

[tvanstiphout]

@eric: in your Frameworks article I see a tradeoff: you make owecFrm Public, so you can later destroy it. I'm sure you entertained the thought that it should really be a Private variable. What are the pros and cons you see?
I am keeping mine Private, but that requires me (or my code generator) to write code in Form_Close.