Is there an obvious way to do this in python?

[H J van Rooyen]

 "Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote:



| On Thu, 3 Aug 2006 16:50:15 +0200, "H J van Rooyen"
| <mail at microcorp.co.za> 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...