OK.
I've just thought what if I'm unable to get global request/config out
of every piece of my code.
Today I have a helper function that utilizes config, environ, and I
call it from templates
just like ${h.help_me('arg')}.
So do I supposed to call it in 1.1 like
${h.help_me('arg', self.request, self.config,
self.whatever_request_context_I_need_there)}?
instead of importing globals in lib/help_me.py?
I believe the beauty of Pylons and Python, is that it allows a minor
magic in favor of nice readability.
As a framework user, I don't need a pure OOP design of it. I just need
a tool to do the things.
So globals are good in many situations, and request/response/config is
really of nothing magic in them.
They just need to be accessible out of everywhere in app.
Instead, it is much worse to add request/response accessor to every
pylons object that needs access to them.
It adds a real complexity that the framework needs to avoid. Few
simple global objects are preferable to me.
Python is not Java, not "everything is object".
This is why I love Python, and switched to it. It has nice compromises
in its design that helps a lot in daily life.
On May 31, 9:30 am, Mike Orr <[email protected]> wrote:
> On Sun, May 30, 2010 at 6:19 PM, Wyatt Baldwin
>
>
>
> <[email protected]> wrote:
> > On May 30, 5:43 pm, Hans Lellelid <[email protected]> wrote:
> >> On May 30, 5:40 pm, Wyatt Baldwin <[email protected]> wrote:
>
> >> > On May 30, 2:31 pm, Eugueny Kontsevoy <[email protected]> wrote:
>
> >> > > They work, but we needed to have our existing 0.9.7 Pylons
> >> > > applications to
> >> > > work and they don't access config objects via TestResponse. In fact
> >> > > 90% of
> >> > > our tests are units, i.e. they don't issue request/response, they just
> >> > > do
> >> > > "from pylons import config" and test business logic in isolation from
> >> > > request/response machinery.
>
> >> > Going a little off-topic here, but in my view, business logic
> >> > generally shouldn't rely on Web app configuration.
>
> >> That's both unhelpful to the discussion and nonsensical.
>
> > Well, that's, like, your opinion, man, but I happen to think
> > differently. The way that it might be helpful is that when you run
> > unit tests against your business logic,
>
> Different people define "business logic" more widely than others, and
> I think the individual application also plays a role. Complex
> applications, or cases where multiple applications share some code or
> data, are examples.
>
> I define business logic as the same as the model, plus whatever extra
> code is in lib or in shared modules. I generally don't use 'config'
> or any of the magic globals in these places. That's partly because
> I've had to port a lot of code from one framework to another over the
> years, and it's easier if the business logic doesn't have
> framework-dependent parts. So my model never depends on other parts of
> Pylons, so that it can be imported standalone for utilities
> (maintenance scripts or cron jobs). Of course, the top-level script
> has to initialize the model with an engine.
>
> For things like a second database connection for a shared module
> (e.g., a stats database), or a search index or such, I put under
> 'app_globals' for the controllers/templates, but I also try to make it
> not dependent on 'app_globals' for testing.
>
> I haven't figured out a way to do comprehensive testing within the
> Pylons structure. For instance, how to hide tests that should only be
> run on special occasions, or multiple levels of "unit" tests. I find
> myself declaring everything in a TestController even if it's a unit
> test, in order to have convenient access to the config. Sometimes I
> recast my tests as standalone scripts to hide them from the regular
> "nosetests". And 'websetup' is not really flexible enough to deal with
> all the data situations you might want to test against -- while
> remaining compatible with its primary role of setting up the databases
> initially. So I'm not really satisfied with the existing test
> infrastructure, but I haven't found anything better either. (Although
> 'twill' works great to quickly test a few URLs.)
>
> >> I've griped about this before, but I think the biggest (only?) problem
> >> that comes up repeatedly for us w/ Pylons is the inaccessibility of
> >> these "special" globals from tests (without using response/request
> >> objects). Stacked object proxies. I dream of a day (or a fork) when
> >> these are either a thing of the past, or disabled by default. (Mike
> >> has given me some pointers in the past, but I still maintain that
> >> writing tests shouldn't be so hard. -- and one shouldn't be forced to
> >> use the WebTest framework, which IMO is inadequate for services
> >> applications.)
>
> As Ben said, SOPless usage is coming, and I keep bugging him about it.
> In frameworks in general, there are three general ways to access the
> request's context. One is via a 'request' argument or 'self'
> attributes. Quixote 1 had a request argument, while Quixote 2 has
> global functions (get_request(), get_response(), get_publisher() [the
> framework object]). CherryPy prefers threadlocal globals, which are a
> precursor to Pylons' StackedObjectProxies. They are convenient, but
> they're also magical, and it ties your code to the framework if you
> use them everywhere (including in lib functions and the model).
>
> --
> Mike Orr <[email protected]>
--
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.
