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 <varin 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
