>
> On Jul 7, 6:58 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
>> That's my point. Unit tests should not be testing things that use
>> 'g'. Low-level routines should not use 'g'. Only at the higher
>> integration layer (e.g., controllers) should 'g' get involved.
>
> Let me rephrase this:
>
> having this code in my Pylons app causes me lots of errors and
> failures
>
> class Form_Register(_Schema_Base):
> email = formencode.validators.Email(not_empty=True)
> us_stateformencode.validators.OneOf( g.us_states.keys(),hideList=True)
>
> I'm not testing g or accessing it during the test. I'm just having
> the misfortune of referencing g in a module.
It's not a misfortune, it is a bug. g is *contextual* to an app's
*instance* so there's no way you can expect to work properly at the module
level since you have little control over what g will be really pointing to
when the module is imported. The fix is as easy as:
def get_Form_Register():
class Form_Register(....):
... g.us_state_keys()
return Form_Register
And then call get_Form_Register() inside the controller's actions where
you know for sure g will be properly initialized.
Better still, don't use g for this. Use a cached query:
# Inside some module
@beaker_cache(...)
def us_states():
return model.States.query(model.States.c.country_code == 'us')
A rule of thumb I try to follow that has save me much troubles (after
causing me many more) is to make module imports as side-effect free as
possible.
(....)
>> Putting database lookup values into 'g' was an idea I had not thought
>> of. When I've come across that situation, I put a function in the
>> model that returned or updated a cache dict (module global). It is
>> assumed this function will be valid only if init_model() has been
>> called. Of course it will fail with a predictable "no database engine
>> available" error if this is not the case. Now, this structure is safe
>> if the data does not vary across application instances coexisisting in
>> the same process, and is ideal if it's read-only. If the data does
>> vary across application instances, you'll have to put it on 'g'
>> because that's what 'g' is for -- as a safe place to put
>> application-instance-specific data.
>
> That could work - but at the expense of needless code.
It's not needless if it is needed for the thing to work properly ;)
> I need these constants when:
> - displaying a form
> - validating a form
> - validating API or other values
> - printing information to the end user
>
> doing a model call every time would work - but at the expense of
> repetitive queries. for all intents , this data are static and a
> dict.
pylons.cache. It will even make your app scale more easily since you can
transparently switch to memcached once your app grows over more than one
machine and if, for any reason, the data your storing turns out to be less
static than you thought (eg: the admin interface is extended to allow to
edit the list of available languages)
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
