Nicely put, Dennis. Regards, Alastair.
----- Original Message ----- From: "Dennis McGrath" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 23, 2002 9:46 PM Subject: Thoughts on proposed STATICVARs > I think a new thread is in order here. > > My suggestion for an enhancement for STATICVAR comes from 17 years of use of > RBase, as well as recent forays into VB and object oriented programming. > > I suddenly realized that so much of what I did for years to make my apps > easy to maintain was, in effect, an attempt to make all parts of the > app/database self sufficient. That is the key idea in object oriented > thinking. You create objects that when called upon, have everything they > need to correctly instantiate (a fancy word for create) built in. Once you > have the object created, you can alter properties to make them give you > results based on those adjustable properties. > > My recent post describing how I put variable definitions in my forms that > referred to themselves was a way (although an awful kludge) to make my forms > maintainable without having to remember to define certain variables > beforehand. > > This has at least two advantages: > 1. I can maintain the form without predefining anything. > 2. There is a greatly reduced probability that I (or my clients!) will save > the form in an unusable state. > > This has at least two disadvantages: > 1. It uses up a valuable resource: variable definitions in a form. > 2. The definition is a mystery to anyone who does not realize what it is > there for. > > In RBDOS, anything over 100 variable definitions is asking for trouble. > In RBWIN I have not yet run into the variable definition limit, but suspect > it is lucking there. > > To sum up, Forms created in this way are friendly to me, the developer. > They save me tons of time because I don't have to remember anything. I also > don't get error messages when I try to maintain forms. > > But, there is one problem which keeps coming up. Forms created on views > with embedded variables are not so friendly. They complain about missing > variables, and they complain about illegal comparisons like null dates. The > problem is that views with variables are not self contained objects like > normal views. They rely on certain variables to exist and, in some cases, > that they contain valid data. > > One could wish that the forms could process their variables before trying to > check the underlying table, but that does not solve the limited variable > resource issue, and it is not really the correct solution. > > One could wish that the views themselves could maintain these variables, but > I suspect that would be an unnecessary complication. And it would not solve > the need for other predefined variables that the forms or reports might > need. > > The only really satisfying solution to this problem is if the database > itself maintains the desired variables. After all, views and forms are > objects contained in the database. So, if the database has the ability to > enforce properly defined required variables (STATICVARs), all these problems > go away. This is because the container object (the database) assures that > all contained objects are always happy. > > The upshot of this is that I can be a responsible developer just once for > each view, form, etc. I create. No code needs to be run once the database is > opened. This makes me look good. This makes RBase look good. This makes > the client happy (lower maintenance cost). These are all appropriate and > valuable goals. > > --Dennis McGrath > > > > > > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
