"Dennis Lee Bieber" <[EMAIL PROTECTED]> wrote:
| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen" | <[EMAIL PROTECTED]> declaimed the following in comp.lang.python: | | > | > This is broadly what I had in mind, yes - but sort of down to a transaction | > level - this user does invoicing, this one enters cheques, this one does credit | > notes, and their supervisor can do all three, and in a different department its | > different because the jobs are different, but the invoicing GUI module is the | > same for wherever its used... | > | Confusing use of "transaction"... Many are probably looking at | "transaction" in terms of DBMS -- eg: a sequence of SQL operations | (inserts/updates/deletes) that ALL must be successful (and committed) | or, if any operation fails, ALL operations will be undone (rolled back) | as if none had been performed. | | What you describe is something I'd refer to as different operator | "tasks". Sorry - I have spent too long in an environment where a transaction is something you built, shipped, and got an answer for... | | For this control, and presuming you do NOT want to use a web | interface, I'd still build all capability (ie, all menu and form | definitions) into the client that is installed on all user stations. | THEN I'd use the application server (since I still feel you want to | control access to the database to one central point, not have to create | a user account in the DBMS for each employee using the clients) to | handle a login from the client -- the login would be used to access a | privilege table from the DBMS. This privilege table is essential a long | record of booleans -- one for each menu/form/task in the client. The | privilege record is sent to the client; the client uses the record to | enable and disable the relevant menu/form/task so that the user can only | activate the functions valid for them. | *grin* this is the easy - cop out route - there is of course nothing intrinsically wrong with it - I was just trying to find out how to do the harder bits in Python - namely to dynamically present different things... | Otherwise you have a situation where, say a lowly data-entry clerk | has been using the application, maybe makes a mistake that requires | supervisor override, and the supervisor then has to wait for "their" | modules to be downloaded and started to correct the mistake. (Note: one | menu entry that should be on the "all-in-one" client is an ability to | change login without having to shut down the client -- basically the | client does a log-off of the application server, then a fresh log-in | with new parameters and gets a new privilege record with which to | reconfigure all the menu/form/task GUI). | This is a disadvantage that I had not thought about - I was not yet this far down the track | If you go the web application route, each "login" would use a cookie | to control session, so the application server can determine what | functions to present to the user. You might even be able to use | something like Plone to build the application server; it already has | capability to present different views based upon login. Know squat about Plone - another thing to add to my list of reading *sigh* | | > My thinking is simpler than this, because you are already thinking in "data base | > speak" - now dont get me wrong - I realise that I will have to use a database - | > but for me to start thinking in terms of views and stuff is kind of premature | > when I dont even have a clear picture in my head of the kind of data the said | > management system should keep, as I am not sure of what can, and cannot be done. | > | We're talking computer software -- enough money and time and you | could have the sun, moon, and stars (granted, a decade ago I /was/ | involved with swapping out one satellite ephemeris package for another, | so it was literally sun, moon, and stars <G>) | sounds like it was fun... | You need to determine | | 1) architecture partitioning (DBMS <-> thick client; DBMS <-> | application server <-> thick client, DBMS <-> application/web server <-> | thin client) [Thick client: Python program that handles GUI and talks to | application server or DBMS; Thin client: web browser forms with some | Javascript/AJAX]. I am kind of egregious - despite all the sound advice I am getting - I am still thinking (from the back end) of: dbms <> app server <> thick client (python) | | 2) Database schema (done without care of the final DBMS); take into | account things you may not think of as the main data of the application | -- things like the above privilege control (in the case of the | DBMS<->thick client, it means using the grant tables and managing client | accounts per user, in the application server model you only have one | DBMS user that is the application server, but still have client user | accounts to manage as application data). If the DBMS has stored | procedures, you may need some of those... Heck, in the DBMS<->thick | client model, you could let any client access ANY form/operation/task... | What you'd do is run stored procedures for any DBMS transaction -- the | first thing that would happen is that the user privileges are checked | and the stored procedure either proceeds or rejects with "no privilege | for operation" (and this could be either programmed in as part of the | stored procedure, or be part of the DBMS internal privilege control). | -- Yes this is the tricky part - it is so easy to overlook something, or to use an awkward definition that comes back later to byte you in the butt (yes I know bite is not spellt like that) And it is not easy to do all this so that you can maintain it - when you get back to it six months (or years) later, you are no longer the same person... the "Who wrote this crap? " syndrome - and the answer - "Oh it was I" ;-) So one has to follow some kind of discipline that you feel comfortable with... Thanks for the input - I want to call "time out" now so that I can go and do the reading I have been pointed to... -- http://mail.python.org/mailman/listinfo/python-list
