I thought I'd 'got' globals but...

[Bruno Desthuilliers]

meridian a écrit :
> Bruno Desthuilliers wrote:
> 
>>meridian wrote:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>>
>>>>def doIt(name=None):
>>>> global gname
>>>> if name is None:
>>>>   name = gname
>>>> else:
>>>>   gname = name
>>>>
>>>
>>>
>>>Thanks Bruno, works a treat...
>>>
>>
>>But still very probably a bad idea.
>>
> 
> Ok, my curiosity is pique'd - is there a better way to hold my
> app/module globals?

Probably !-)

Now which one depends on your app design and execution model...

> I must say I'd prefer not to write global <var> in every function, for
> every global var I need.

> Maybe there's a simpler way to structure?... by a global class or
> something?

<ot>What is a "global class" ?</ot>

The problem with "app globals" is that they introduce too much coupling 
(you end up having all your code depending on the globals). So the first 
thing to do is identify who really needs to know what, and who is 
responsible for knowing what. Anyway, most globals should be 
configuration stuff - so usually read only. There are very good reasons 
to avoid modifying globals in functions, and specially when it comes to 
web programming where you have to handle concurrent access (which is why 
I insist on telling you that what you want to do may be very dangerous).

Usually one uses a variant of the MVC, which helps separating concerns : 
the model is about data (structure and persistance), the view(s) about 
outputs (display data), and the controler about inputs (processing the 
request). The flow is something like: controller parses request, takes 
any appropriate action, selects appropriate elements from the model, 
feed'em to appropriate view, and returns the result of view execution as 
a response (general scheme, depends on whether it's plain cgi, 
mod_python, fastcgi, wsgi, standalone server or whatnot).

It's clear that the controler needs some knowldge about the model and 
the views, that the views are tightly coupled to the model but don't 
need to know about the controller, and that the model just don't give a 
damn about both controller and views. So we have:

controller -> depends on model and view
view -> depends on model
model -> depends on nobody

Since handling a request is the controller's duty, the model should not 
know about the request. The only 'global' things the model has to know 
are related to data access configuration (db connection string, physical 
path to resources on the filesystem etc...). Since the model is called 
by the controller, it's the controller's job to pass these informations 
to the model when appropriate.

Views may also need to access app-wide settings like urls to resources, 
localisation stuff etc. Here again, since views are invoked by the 
controller, it's usually the controller that is responsible for passing 
relevant knowledge to the views - either directly (raw data) or 
indirectly (thru some helper objects that holds the required knowledge 
and are called by the view code).

As you can see, you've already eliminated any needs for globals in both 
the views and the model (view or model specific module-level 
pseudo-constants set aside, but then it's mostly safe).

I don't know which web solution you use, but I strongly suggest that you 
take some time studying existing web applications or frameworks like 
Trac, Django, CherryPy etc.

HTH