[AccessD] Frameworks

>  I think you'd get a little more mileage out of the discussion by asking
if anyone has built a framework or used one regardless of product and if so,
what services were offered.  What a developer needs to produce an app can be
somewhat generalized at first.  Later you could focus on specifics that
relate to Access (like passing/parsing Openargs).

I could swear I did that!  8(

>  You've already brought up one in a latter thread; handling multiple
instances of the same form.  There are others, such as providing login,
security, and user tracking within an app.

  Interface elements; progress bar, pick form, pre-built form and control
classes
  Printing; Printer pick, run as PDF
  Low level; generate surrogate PK's, encryption, station identification,
etc.
  Utility; find and replace, line numbering, error handler inserts,
indenting, etc.

Ohhh... Ideas.  I like it.

I think that contrary to popular belief, a book about frameworks is not
about providing a framework ready to go to solve everyone's problems, but
rather about HOW you build a framework to make your job easier.

I have an entire framework written, which works for me, but I know from
experience that other developers will look at that and say "I don't need
that" and "I need this over here" (which isn't in my framework).

My framework was literally written "as I needed it".  I have functionality
in it that I wrote because I needed it at that time, and it was included in
the framework because I wanted to have it for other applications.  In fact I
have a rule which I outline to my clients which goes something like this:

* I write your application.  I use my framework in your application which
saves me a TON of time writing your application because you get the benefit
of prewritten code.  
* Any application specific code that I write (is only useful in your app)
goes in libraries in your app.  
* Any code I write that is useful (in MY judgment) in other apps gets placed
into my framework.  You pay me for all time spent writing code for your
application, whether or not the code ends up in your application or in my
framework.  
* I OWN MY FRAMEWORK.  
* You get a license to use my framework, not to include distribution of the
application outside of your company without licensing my framework for that
purpose.  

A framework, by its very nature is a living growing beast.  Nobody can think
of all the useful things that a framework can do across every application he
will write.  We write applications, we say "oh, I have needed that before or
I will need that again", and that code goes out in the framework for the
future.  In this sense, a framework is no different that a library of code
that every developer worth his salt creates.  

Where a (my) framework differs is that a framework directly responds to
events of objects and raises events of its own.  My framework loads clsFrm
and sinks all of the events for the form.  I don't do anything useful with
every one but the hook is there.  When an afterupdate occurs, a collection
of dependent objects is checked to see if any dependent objects needs to be
requeried.  As you move from record to record, a record selector combo is
requeried to sync it to the form.

The form loads classes for controls, passing in the pointer to the control
to the class.  clsCbo, clsTxt etc.  The class hooks events for that control.
As a combo's AfterUpdate fires, a collection of dependent objects is checked
to see if any other combo's, lists or forms needs to be requeried because
their contents depend on that combo.  Some developers write code over and
over to "requery that combo over there when this combo changes".  I wrote a
dependent object collection that every data aware control class contains,
and whenever specific events in that control fire, the dependent object
collection is examined and if there are any class pointers in it, the
requery method of that class is called.  Given this structure, I can now
simply pass in the name of controls to a class method saying that "this
object is dependent on you" and the class finds and loads the pointer to
that object's class into its dependent object collection.  There is one
place in the code in every from where dependent objects are set up.  If you
want to know what is dependent on what, there it is.

Now, do YOU want that functionality?  X percent of you will say "yea I like
that, that's cool", and the other Y percent of you will say "that's crazy,
I'll do it my way".

So a book about building a framework is NOT about handing you a full fledged
framework and explaining how it works, but rather explaining what reusable
code is, what functions and subs are, what modules are, what libraries are,
what classes are, how to place classes in libraries and yet expose them to
the application, what a framework is, how you build one, and why you would
do any or all of the above.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Monday, June 26, 2006 8:11 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Frameworks


John,

  I think you'd get a little more mileage out of the discussion by asking if
anyone has built a framework or used one regardless of product and if so,
what services were offered.  What a developer needs to produce an app can be
somewhat generalized at first.  Later you could focus on specifics that
relate to Access (like passing/parsing Openargs).

  You've already brought up one in a latter thread; handling multiple
instances of the same form.  There are others, such as providing login,
security, and user tracking within an app.

  Interface elements; progress bar, pick form, pre-built form and control
classes
  Printing; Printer pick, run as PDF
  Low level; generate surrogate PK's, encryption, station identification,
etc.
  Utility; find and replace, line numbering, error handler inserts,
indenting, etc.

Jim.