[AccessD] To framework or not?

   I think your opening statement is incorrect;  a pile of parts that can be
made into a car is not a car - it's just a pile of parts.  It doesn't become
a car until it's assembled.  Proof of point: I can dis-assemble a car into a
pile of parts and then use those parts to make something other then the car.
For example, I might make a trike.

  And a car once assembled can only function in one specific way.  That's
the downside to frameworks; their rigid.  Upside is it makes them very easy
to use.  

   Having to assemble a pile of parts every time I would want to go for a
spin around the block would be difficult at best.   But if today I need a
trike instead of a car, then having a car won't do me much good where as a
pile of parts would. 

  Somewhere in between those two ideas is a balance.

  Personally I like frameworks for application level services (like your
security system, menuing, logins, etc).  But all too often frameworks become
bloated because they need to allow for variation in logic while still being
rigid and that's their downfall.  You end up with a lot of code and overhead
for things you may not need today, but might tomorrow (aka .Net)

  For example, the next customer that comes along may want security down to
the field level, so you build that in.  But the next twenty want security
only to the record level, or maybe not even at all.

Jim.  
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, September 01, 2010 2:10 PM
To: Access Developers discussion and problem solving
Subject: [AccessD] To framework or not?

You can own a car, which consists of every single part of the car, just
sitting in a pile (or even 
neatly stored in parts bins on shelves.  Technically you own a car but that
car doesn't inherently 
do anything, and in fact can't do anything.

Or you can have that same car, with every part assembled where it is
supposed to go, sitting in your 
driveway.  Now the car can do things.  Because the parts are assembled where
they are supposed to 
go, when you turn the key electricity starts to flow.  A solenoid kicks in,
extending a starter gear 
to the engine and starts causing the engine to rotate.  Electricity causes
the fuel pump to pump 
gas, sparks start to fire and the engine roars to life (hopefully).

Same car, just in a different state.  Instead of a pile of parts, it is a
system of parts which can 
perform work "all by itself".  Pressing buttons can cause seats or mirrors
to move.  Moving the 
gearshift can cause a chain reaction that causes the transmission to start
working.  Pressing the 
gas pedal causes the engine to rev, and if the transmission is engaged the
transmission starts to 
apply power to the drive shaft.  Teeny little stimuli applied by a user
causes massive state 
changes.  But the user doesn't have to intentionally do massive things, just
teeny things.

Some people use libraries, which are collections of functions.  Each
function does something but in 
general it is just a pile of functions.

I write frameworks.  When I turn the key, (call a single initialization
function), code starts to 
execute.  SysVars Load, security information loads about groups, users and
users in groups and 
caches that info to structures in the framework.    A login form opens and
forces the user to login. 
  As the user logs in, the framework takes the user's loginID and looks it
up in the user cache, 
then runs the password through an MD5 hash function.  The resulting hash
code checks whether it 
matches the password hash from the user cache.  If so then the framework
saves a pointer to the 
logged in user into a variable in my framework object.  If not the user is
told to try again.

Once the framework is initialized, it is sitting there monitoring what is
happening in the application.

When a form loads, a form class is initialized.  It immediately checks its
security (the groups that 
can open the form) against the logged in user's security groups.  If any of
the groups match, the 
form continues to load (doing still more framework kind of stuff) otherwise
the user is informed 
that (s)he is not allowed to open that form.

Same library, just in a different state.  Instead of a pile of functions, it
is an assembled system 
that can perform a work all by itself.  I apply teeny little stimuli and the
framework responds 
entirely automatically.  Loading three lines of code in the form causes an
entire validation 
functionality to occur.

-- 
John W. Colby
www.ColbyConsulting.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com