[cgiapp] Design question

[Bodo Schulze <suppressed>]

Hi all,

after finishing my first C::A application -- allowing some friends who
are running a small bookstore in the neighbourhood to manage their
catalog --, I would like to express my gratitude to all of you who
developped und contributed to C::A, H::T and their plugins. It's just
great to programm within this framework. Thanx a lot.

Now, I'm setting out to enlarge this first project. As my friends sell
their mainly ancient books not only via their local bookstore, but
also via the internet, there is need to manage the whole cycle
including ordering -> invoice [ -> reminder ] -> payment. The last
stage of this cycle should write tables a future ledger modul could
build upon.  So I lurked around for some Perl application doing just
this. SQL-Ledger seemed the appropriate tool. But then, digging into
the code, I felt like beeing back in pre-C::A stone age. Oh no, not
this!

I then tried to figure out an appropriate C::A class hierarchy
allowing for extensibility and customization. As this is my first OO
project involving a whole bunch of classes, I am not sure whether I
found the right approach, and so I would like to submit to your kind
attention what I came up with. Any comments are welcome.

1. Order, Invoice, Reminder, Payment

Each of these will get its own C::A. On the other hand, they are not
really different objects, but rather transitional states of one
object, i.e. states of a transaction. On the db-level, all transaction
infos get recorded in the transaction table containing the fields:

     * ID
     * customer_id (or vendor_id)
     * open_date
     * closed_date
     * order_date
     * invoice_date
     * reminder1_date
     * reminder2_date
     * reminder3_date
     * payment_date
     * status [ order | invoice | reminder1 | reminder2 | reminder3
                      | payment ]
     * origin [ webshop, other online catalogs ]
     * notes
     * currency
     * payment_mode

(The ordered books get recorded in a relational table linking
transaction_id to book_id)

On the C::A level, since Order, Invoice, Reminder and Payment are
meerely modifications of a transaction, they inherit from transaction:

       Transaction
           |
            ---> Order
           |
            ---> Invoice
           |
            ---> Reminder
           |
            ---> Payment
           

2. Furthermore, there are not only customer transactions (selling
   books), but also vendor transactions (buying books). This yields:

      _Transaction
           |
            ---> _Customer
	   |        |
	   |         ---> Order
	   |	    |
	   |	     ---> Invoice
	   |	    |
	   |	     ---> Reminder
	   |	    |
	   |	     ---> Payment
           |
            ---> _Vendor
                    |
                     ---> Order
                    |
                     ---> Invoice
                    |
                     ---> Reminder
                    |
                     ---> Payment

3. To manage customers und vendors, we need:

       _Partner
           |
            ---> Customer
           |
            ---> Vendor

4. And to manage the book catalog and provide an interface to
   wholeseller catalogs:

       _Article
           |
            ---> Customer (here's where my first C::A would plug in)
           |
            ---> Vendor

5. The three abstract base classes _Transaction, _Partner and _Article
   in turn would inherit from a common base class representing the
   whole application, which also includes a report module (responding
   to invocations like "write a list of all customers having open
   orders") and could later on include a ledger module:

       _Anares (the name of the bookstore)
           |
            ---> _Transaction
           |
            ---> _Partner
           |
            ---> _Article
           |
            ---> _Report (not sure whether I should subclass it 
           |              for Transaction, Partner and Article)
           |
            ---> _Ledger (the future)

The base class _Anares provides some common runmodes the derived
classes may overwrite:

  * store, update, erase 
  * display_form, update_form
  * print, email, pdf-attachment, fax

I am not sure whether this deep hierarchy is really necessairy, I'm
just looking for a maximum of extensibility.

For example, having store() up in _Anares allows a sort of plugin
mechanism. SQL-Ledger e.g. records the name of the employee who
inserts an order into the DB. If needed, his functionality could be
implemented in _Anares::Store() and then used by
_Anares::Transaction::Customer::Order::store() via $self->SUPER.

Hoping that all this makes sense to you, I'm eagerly waiting for your
comments.

Bodo

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed