architecture of sm2 - index and commons

[Lewis B. <lbe...@ab...>]

I spent an hour at 1 am last night typing in some architecture stuff just 
to get an error about not being connected anymore with sm. I hope we fix 
this in 2.x!? At any rate this one will probably be a lot better as I won't 
ramble as much.

ISSUE 1 -- index.php
==============
I think that the logical place to enter sm2.x is at the controller. This 
would seem to me to allow a better design of the core libs as just that, -
libs-. If it hits the sqmessage object first then it cannot be extended as 
a true lib should be able to. Maybe I have gotten an inaccurate picture of 
what is envisioned.
Luke seemd to imply that the sqmessage object would always appear in the 
mix. I would argue that this is not only not good design but quite possibly 
not aallow what a lot of people will want to do with sm2 and therefore be 
undesireable.
An example is warrented.
Say there end up to be three or four types of backends that sm2 connects 
to. NNTP, POP, DB, FILE, others. If these are developed as class extensions 
rather than something else. if sqmessage is called directly then an 
extension gets left out it would seem to me. Besides, maybe someone else 
doesn't even want to call sqmessage (don't ask me why they would want that 
but I bet someone would). Then what? I would say keep the libs libs and let 
the controller be the reciever and distributer of results as below.

CORE <---make request --- CONTROLLER ---make request --->template
LIBS  ---send response--->  MODULE <----gets response----template

Puts to the core would obviously be for backend connections and gets would 
be variables for display. Puts to the template would most likely just be to 
open it and gets would be the succesful opening. Then the controller would 
put all that together and present that for display and anticipate more 
requests.

I probably did a poor job of explaining this but I'll try again if needed.

ISSUE 2a - a base is needed
====================
I believe that sm2 should have 2 seperate files that serve as a "base" for 
the different classes. Maybe they should be classes themselves to allow 
easy method and variable access. 
This is the reason for me saying this. How many times do you see cvs 
messages where 6 file were changed to impliment one small change? Why? Why 
not for example have base class that all core libs extend? If a common 
function is needed put it in the base module so that any changes to it will 
be automaticly inherited. If a var is checked or used by a bunch of core 
libs why not declare it in the base? This would also allow thae addition of 
new common functions to the core without need to change but one file.. 
This would also allow a constructor to be made that would do the things(if 
any) that all or most core scripts might have to do on their own (there are 
a couple of these in sm1). But I see the big advantage as not having to 
include a bunch of files for every file and the auto updating of all of 
them. I would say strings and date could be to functions that could go in 
such a file.

ISSUE 2b - base fore non-core files
======================
would it be a good idea to have the same thing for non-core libs? Say 
alternating row colors is a common thing the different controllers have to 
do. Why not include a base in every controller that does two things.
1.includes all core libs
2.has common functions used by most controllers.

This would make it easier to write controllers as well. Thus I assume this 
base or common file would be part of the core but only included in the non-
core files.

Aren't you glad you didn't get the long version? It was repleat with ASCII 
art and the works. At any rate, let me know what you think.