[AccessD] Data Export Spec - Rev1

ROTFL.  

1) I already have the whole thing working, without ever having done anything
like that.
2) Whatever that was that you said, it was Greek to me.
3) I read the original pattern book (or one of the first I think) back in
about 1995, but haven't referred to it since, in fact I think I gave it to a
friend although now that you mention it, I should search my book boxes.  It
was cute, cool, but way abstract.  Now that I am moving toward .net perhaps
it will be of more use to me - I was actually looking at buying a design
patterns book (it's in my "to buy later" list at Amazon.com).

Without collecting the requirements, how can I say anything about the
classes, what they will look like, or how they will interface?  All I did
was discuss (VERY briefly) how I had already done this.

As I mentioned, I already have a solution up and running.  I wrote it about
a year ago.  I know what I needed, I know the table structure I used, which
worked for my purposes.  And BTW, it was both intelligent and worth using.
I wrote it precisely because I was getting revisions to the export format
spec on a regular basis and got tired of trying to keep up with that so I
just wrote a table driven design.  It works.  I have had to insert a dozen
fields right in the middle of the (~2000 byte) string and it was a simple
matter of adding more records in the field table, and changing the order
field so that they were inserted in the right place.  It took me a few
minutes to modify the query that pulls the data to be exported, and about 15
minutes to add the field records, reran the export and out pops the data
just as the (new) spec says it should look.  I do a fixed width for the
export, and a CSV for in-house use.

I know the classes that I used, and how they interacted.  I can describe
that to you and you can write the gobbledygook if you need it.  I would
certainly be interested in reading the gobbledygook when you are done.  I
shamefully hang my head and admit I didn't write a spec before writing the
solution I created last year. I work in Access, in VBA, and I have no need
for an abstracted "devoid of any programming language" specification.  OTOH,
this thing was pretty simple, just a pair of classes.  What we are about to
do will be a bit more complex in order to handle the general case.

BTW, I also wrote an interprocess communication class, using withevents.  It
is a SINGLE class, having TWO functions, a total of 14 lines of code, and
works a treat.  Of course it has no queue, it just broadcasts a message
(raises an event, passing parameters).  Anyone can broadcast, anyone can
listen.  You can find it on my web site in the Withevents demo.

And no, I didn't write any specification before I wrote that either.  How
will I ever look myself in the mirror tomorrow?

I do think we need a good spec writer though, if you want to volunteer for
that position.  And yes, we do need someone to help us get this thing
working with SQL Server as well.  Since you will have written the spec, I
assume that you will be comfortable in knowing that it is intelligent and
worth using.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, October 22, 2005 10:24 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Data Export Spec - Rev1


That is all very nice, JC, and as a reasonably well qualified SQL person I
might even be prepared to volunteer, but I must second Shamil's comment
about you diving into details right away. I need an introduction to what the
class is intended to do and what methods it supports and what they are
intended to do -- all in language-agnostic English with not a single
reference to Access, ADO, DAO or any such underpinnings. 
Then, and only then, IMO, can we get past our preconceptions, habits, etc.
and design something both intelligent and worth using. For example, the
various Patterns things have been implemented in many languages. 
Without referring to a single programming language, document the 10
components and give some examples of how you expect a developer to combine
them into something useful. For example (not that this immediately concerns
the current project)... Class 1: FormReferee Class 2: Form Class 3:
FormMessage Class 3 describes a Message object which must contain attributes
A, B and C, and may optionally contain D, E and F. In addition, it contains
a Post
(sender) attribute and a Get (receiver) collection. (A single message cannot
be sent by more than one form, but may be Received by many forms.) Class 2
is the foundation for all forms used in the system, and contains a Post and
a Get method, each working with a queue. The former packages the message and
posts it to the FormReferee. (As stated in the foregoing paragraph, the
given form may Post a message to more than one form, or even to all open
forms.) 
The FormReferee merely collects the messages in either appropriate queue. It
is up to each form to interrogate the Sent queue, looking either for its own
name or for messages with no recipient (i.e. all). 
Messages Received by the given Form go into its MessageQueue and are
processed in the order Received. A message object contains a collection of
Getr-forms. 
If the collection is empty, the message is intended to be sent to all open
forms. Otherwise the message is sent to the member-forms comprising the
collection of forms. It may occur that one or more forms in the collection
are not in fact open at the moment the message is sent. Class 1 is a
singular class (one instance only), and referees all interactions between
all forms. It uses two queues, each containing FormMessage objects. It also
uses a list of all open forms. Any given message may be sent to one
particular form, to N forms, or even to all forms. Messages sent to forms
that are not open are ignored.
-------------------
This was improvised so it may have numerous holes, but it was intended as an
example of the introduction to each class that I find sorely missing in the
emails presented thus far in this thread. Regardless of its shortcomings,
the above 
a) attempts to describe the purpose of three interacting classes and the way
in which they collaborate;
b) avoids any specific programming language 
----------------------------
A quick re-read suggests several changes:
a) No need for two queues in the Referee; one will do.
b) The Referee may need a collection of all open forms to make this work
efficiently. The next item explains why.
c) The queue should be a special-purpose stack (i.e. a message is received
by all relevant open forms, the message is removed from the stack). But I
hope that you get the idea. The programming language is not mentioned; that
is the big idea. The code is not specified; that is the second biggest idea.
All that is described is the nature of the classes and a couple of their
messages, along with an indication of their intended interaction. IMO, you
have to get all this down first before you even begin to describe all the
details. Bottom-up class design, IMO, is doomed to fail. A.