Adding configuration to View to dispatch to any methods.
Hello, and Happy new year, everyone. Please listen to my proposal. I want django.views.generi.View.dispatch method to call methods in consideration of some config. For example, calling methods depending on the value of the request parameter. So I wrote this commit: https://github.com/hirokiky/django/commit/e3399495dca9a727568626f64e2fa276c2857da9 Description of this implementation --- View.dispatch_config takes a dictonary. Keys of dispatch_config are HTTP method name as target. Values are `predicate` dictionary. Key of `predicate` is method name which you want to call to. It's `receiver`. And the value of `predicate` is `predicate function`. When the function returns True, dispatch method calls `reciver`(target method). Since my English is not good, plead watch this Gist (for usage). https://gist.github.com/4433362 Solution I proposed may be not adequate. but I want dispatch method to be more flexible. Thank you. -- 清原弘貴 (Hiroki KIYOHARA) mail: hirok...@gmail.com http://hirokiky.org/ @hirokiky -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding configuration to View to dispatch to any methods.
Hi Hiroki,
Thanks for the suggestion, but I'm afraid I don't see the benefit of doing
this as configuration, rather than something in the dispatched method
itself. Using your gist as an example -- why should this be something
defined in a custom dispatching configuration format, rather than simply
defining:
def get(self, request, *args, **kwargs):
if kwargs.get('corn') == '1':
return HttpResponse('pony with corn')
return HttpResponse('pony')
Using this approach, you can be explicit about what you want to do; a
developer reading the code requires no special knowledge to understand how
it works (it's just standard Python code); you don't need to wrap the
predicate up in to a function; it allows for more complex logic that can't
be expressed as a simple predicate; and at the end of the day, it's less
code as well. What's the advantage to your proposed approach?
Yours,
Russ Magee %-)
On Wed, Jan 2, 2013 at 6:09 PM, Hiroki Kiyohara wrote:
> Hello, and Happy new year, everyone.
> Please listen to my proposal.
>
> I want django.views.generi.View.dispatch method to call methods in
> consideration of some config.
> For example, calling methods depending on the value of the request
> parameter.
>
> So I wrote this commit:
> https://github.com/hirokiky/django/commit/e3399495dca9a727568626f64e2fa276c2857da9
>
> Description of this implementation
> ---
> View.dispatch_config takes a dictonary. Keys of dispatch_config are HTTP
> method name as target.
> Values are `predicate` dictionary. Key of `predicate` is method name which
> you want to call to. It's `receiver`.
> And the value of `predicate` is `predicate function`. When the function
> returns True, dispatch method calls `reciver`(target method).
>
> Since my English is not good, plead watch this Gist (for usage).
> https://gist.github.com/4433362
>
> Solution I proposed may be not adequate. but I want dispatch method to be
> more flexible.
>
> Thank you.
>
> --
> 清原弘貴 (Hiroki KIYOHARA)
> mail: hirok...@gmail.com
> http://hirokiky.org/
> @hirokiky
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Using condition on signal.post_save()
I am using django 1.5b2 and custom user models. I have a method in model managers, create_inactive_user(). Activation codes for users are on a different methods, Activation. I want to have an entry created in Activation table, to correspond against the inactive user. What I am using right now is. def create_activation_code(sender, instance, created, **kwargs): print 'The signal is called' if created: print 'the singal goes to created' if not instance.is_active: print 'the signal evaluates the active state' activation = Activation.objects.create(user=instance) activation.get_code() activation.save() else: print 'the signal fails to evaluate active state' Is there a way that i can process conditions inside a signal? or can i do something inside my model manager method to reflect this action? help in this regard would be obliged. link for stackoverflow question is here. http://stackoverflow.com/questions/14115033/django-1-5-using-condition-on-signal-post-save //ysfjwd -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/U8UtHb0K7HoJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Using condition on signal.post_save()
This mailing list is about the development of Django itself, please direct user questions to django-users. Regards, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/1OHG4hDKzcIJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
+1 on the idea of just adding PROJECT_ROOT official setting and using that as needed - this is what I do in my projects already. -Original Message- From: Luke Plant Sent: Sunday, December 30, 2012 6:01 PM To: django-developers@googlegroups.com Subject: Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694) On 29/12/12 04:08, Cal Leeming [Simplicity Media Ltd] wrote: Could we not have something like this in the settings.py, which in turn enabled the code pasted above? TEMPLATE_PATH_RELATIVE=True For consistency, we'd need STATICFILES_PATH_RELATIVE, STATIC_ROOT_PATH_RELATIVE, MEDIA_ROOT_PATH_RELATIVE etc. which is craziness. Having just one extra setting is a big deal. There are use cases for all of these being absolute paths (or at least some of them), and use cases for all of them being relative. We've already chosen absolute paths, and you can generate absolute from relative using os.path.realpath etc. The only option I can is whether we put that snippet of code (e.g. PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the settings file generated when starting a new project. Luke -- "If we could just get everyone to close their eyes and visualise world peace for an hour, imagine how serene and quiet it would be until the looting started" -- Anon Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. Daniel Sokolowski http://klinsight.com/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.5 release plans
Hi team, Thanks for amazing job! But an update about the release date would be really great :) Thanks Yann Beaud Le mardi 11 septembre 2012 16:22:20 UTC+2, Jacob Kaplan-Moss a écrit : > > Hi folks -- > > I wanted to fill everyone in on our plans for the Django 1.5 release. > The highlights are: > > * Feature freeze October 1st, final out before Christmas. > > * One marquee feature of Django 1.5 is experimental Python 3 support. > This is where we need your help the most: we need to be sure that our > support for Python 3 hasn't destabilized Django on Python 2. We need > lots of testing here! > > * Most features of 1.5 have already landed, but we're also hoping to > land the new pluggable User model work, add support for PostGIS 2.0, > start the process of deprecating django.contrib.localflavor, and a few > other small things. > > * This'll be our first "master never closes" release: work, including > new features, can continue to land on master while we ship the > release. > > Please read on for details. > > Timeline > > > Oct 1: Feature freeze, Django 1.5 alpha. > Nov 1: Django 1.5 beta. > Nov 26: Django 1.5 RC 1 > Dec 10: Django 1.5 RC 2 > Dec 17: Django 1.5 RC 3, if needed > Dec 24 (or earlier): Django 1.5 final > > (All dates are "week of" - we'll do the releases that week, though not > neccisarily that exact day.) > > Notice the longer-than-usual timeline from beta to final. We're doing > this to provide some extra time stablizing the release after landing > the Python 3 work. Please see below for details and how you can help. > > Python 3 support > > > Django 1.5 includes experimental support for Python 3 (it's already > landed on master). We're taking a "shared source" approach: Django's > code is written in a way that runs on both Python 2 and Python 3 > (without needing 2to3's translation). This means that we've touched > nearly the entire codebase, and so the surface area for possible bugs > is huge. > > WE REALLY NEED YOUR HELP testing out Django 1.5 *on Python 2*. Please > grab master, or one of the upcoming alpha/beta/RC releases, and test > it against your apps and sites. We need you to help us catch > regressions. > > We're not yet recommending that people target Python 3 for deployment, > so our main focus here is ensuring that we're still rock-solid on > Python 2. If you *want* to give Python 3 a whirl things should be > pretty solid, but we *especially* need real-world reports of success > or failure on Python 2. > > Features in 1.5 > --- > > Besides the stuff that's already landed (see > https://docs.djangoproject.com/en/dev/releases/1.5/), there are a few > other features we're hoping to land: > > * The "pluggable User model" work (Russell Keith-Magee). > * Some early low-level schema alteration plumbing work (Andrew Godwin). > * Moving django.contrib.localflavor out into individual external > packages (Adrian Holovaty). > * Support for PostGIS 2.0 (Justin Bronn). > * Python 3 support in GeoDjango (Aymeric Augustin). > * App-loading (Preston Holmes) is "on the bubble" - there's some > debate among the core team over whether its ready, but it's close. > > Of course, as with our previous releases, the *real* list of what'll > go in 1.5 is "whatever's done by October 1st". If you want to help > with any of the above areas, contact the person doing the bulk of the > work (listed above) and ask to help. And if you have other features > you'd like to land, get 'em done! > > Master never closes > --- > > This'll mark our first release where "master never closes". > > To recap: in previous releases, once we hit feature freeze we froze > the development trunk, forcing all feature work out to branches. In > practice, this meant months-long periods where new features couldn't > be merged, and led to some stuff withering on the vine. > > That's not going to happen this time. Instead, when we release 1.5 > alpha we'll make a 1.5 release branch right at that point. Work will > continue on master -- features, bugfixes, whatever -- and the > aplicable bugfixes will be cherry-picked out to the 1.5 release > branch. > > The upshot is a bit more work for us committers -- we'll have to be > sure to merge the aplicable commits over -- but no more "sorry you > have to wait three months to merge this work." I'm very happy about > this! > > [Committers: I'm happy to assist with this porting of bugfixes from > master to the release branch.] > > See you on the other side, folks! > > Jacob > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DYtNdlDX9kMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For m
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On Wed, Jan 2, 2013 at 1:36 AM, Victor Hooi wrote: > Hi, > > I may have missed it, but has been a fundamental shift in how Django looks > at projects versus applications, and how they should be laid out? > > I get the impression from Alex Gaynor's comments above that the concept of > "projects" is on it's way out? > > I know there was a change in project layout with Django 1.4, but I thought > things were still more or less the same as before - and projects were still > in. > > James Bennett wrote a blog post way back in 2006 about projects versus > applications: > > http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/ > > I'm wondering if anybody from core is interested in updating that to reflect > current best practices, and the future direction of Django? > James updated his position on that almost exactly one year and one month later: http://www.b-list.org/weblog/2007/nov/09/projects/ My recollection is that the basic premise discussed in that post has been the general view of all core developers since that time (if not before). Search the archives of this list and you'll find various discussions about this - mostly proposals to update the tutorials to not use the "project" concept. Unfortunately, no one has stepped up to do the work. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.5 release plans
Hi Yann, There's [a thread on django-users][1] that should answer your request. >From Russ "It's difficult to give an exact date for the release of Django 1.5. We've put out 2 beta releases, which means there are no more features to be added; and the list of release blocking bugs is down to single figures" There are currently [2 open release blockers][2], so I'd expect there will be a new ETA sometime after those are resolved. [1]: https://groups.google.com/forum/?fromgroups=#!topic/django-users/NyYGM1-db4s [2]: https://code.djangoproject.com/query?status=assigned&status=new&status=reopened&severity=Release+blocker On Wednesday, 2 January 2013 15:37:45 UTC, Yann Beaud wrote: > > Hi team, > > Thanks for amazing job! > > But an update about the release date would be really great :) > > Thanks > > Yann Beaud > > Le mardi 11 septembre 2012 16:22:20 UTC+2, Jacob Kaplan-Moss a écrit : >> >> Hi folks -- >> >> I wanted to fill everyone in on our plans for the Django 1.5 release. >> The highlights are: >> >> * Feature freeze October 1st, final out before Christmas. >> >> * One marquee feature of Django 1.5 is experimental Python 3 support. >> This is where we need your help the most: we need to be sure that our >> support for Python 3 hasn't destabilized Django on Python 2. We need >> lots of testing here! >> >> * Most features of 1.5 have already landed, but we're also hoping to >> land the new pluggable User model work, add support for PostGIS 2.0, >> start the process of deprecating django.contrib.localflavor, and a few >> other small things. >> >> * This'll be our first "master never closes" release: work, including >> new features, can continue to land on master while we ship the >> release. >> >> Please read on for details. >> >> Timeline >> >> >> Oct 1: Feature freeze, Django 1.5 alpha. >> Nov 1: Django 1.5 beta. >> Nov 26: Django 1.5 RC 1 >> Dec 10: Django 1.5 RC 2 >> Dec 17: Django 1.5 RC 3, if needed >> Dec 24 (or earlier): Django 1.5 final >> >> (All dates are "week of" - we'll do the releases that week, though not >> neccisarily that exact day.) >> >> Notice the longer-than-usual timeline from beta to final. We're doing >> this to provide some extra time stablizing the release after landing >> the Python 3 work. Please see below for details and how you can help. >> >> Python 3 support >> >> >> Django 1.5 includes experimental support for Python 3 (it's already >> landed on master). We're taking a "shared source" approach: Django's >> code is written in a way that runs on both Python 2 and Python 3 >> (without needing 2to3's translation). This means that we've touched >> nearly the entire codebase, and so the surface area for possible bugs >> is huge. >> >> WE REALLY NEED YOUR HELP testing out Django 1.5 *on Python 2*. Please >> grab master, or one of the upcoming alpha/beta/RC releases, and test >> it against your apps and sites. We need you to help us catch >> regressions. >> >> We're not yet recommending that people target Python 3 for deployment, >> so our main focus here is ensuring that we're still rock-solid on >> Python 2. If you *want* to give Python 3 a whirl things should be >> pretty solid, but we *especially* need real-world reports of success >> or failure on Python 2. >> >> Features in 1.5 >> --- >> >> Besides the stuff that's already landed (see >> https://docs.djangoproject.com/en/dev/releases/1.5/), there are a few >> other features we're hoping to land: >> >> * The "pluggable User model" work (Russell Keith-Magee). >> * Some early low-level schema alteration plumbing work (Andrew Godwin). >> * Moving django.contrib.localflavor out into individual external >> packages (Adrian Holovaty). >> * Support for PostGIS 2.0 (Justin Bronn). >> * Python 3 support in GeoDjango (Aymeric Augustin). >> * App-loading (Preston Holmes) is "on the bubble" - there's some >> debate among the core team over whether its ready, but it's close. >> >> Of course, as with our previous releases, the *real* list of what'll >> go in 1.5 is "whatever's done by October 1st". If you want to help >> with any of the above areas, contact the person doing the bulk of the >> work (listed above) and ask to help. And if you have other features >> you'd like to land, get 'em done! >> >> Master never closes >> --- >> >> This'll mark our first release where "master never closes". >> >> To recap: in previous releases, once we hit feature freeze we froze >> the development trunk, forcing all feature work out to branches. In >> practice, this meant months-long periods where new features couldn't >> be merged, and led to some stuff withering on the vine. >> >> That's not going to happen this time. Instead, when we release 1.5 >> alpha we'll make a 1.5 release branch right at that point. Work will >> continue on master -- features, bugfixes, whatever -- and the >> aplicable bugfixes will be cherry-
Re: Adding configuration to View to dispatch to any methods.
Hi, Russ.
Thanks for your reply.That makes sense.I notice that the configuration of
my suggestion is complex.
We need to know what the configuration to take the value.It is necessary to
re-consider the implementation.
Advantage of my approach
-
My approaches enables to reuse the condition of the method calling (as
`predicate function`).
For example, considering to header's value, session value or
request.is_secure.
By dispatch_config, we can reuse these conditions.
Yes, in the example, the condition (kwargs.get('corn') == '1') is used only
one time.
And more
--
Now the configuration takes one predicate function, however, thinking the
further reusability,
We can enable the configuration to get more than one function to call one
method, like...
dispatch_config = {'get': {'get_corn_1': (corn_predicate,),
'get_corn_1_secure': (corn_predicate,
secure_predicate)}
}
It is hard to write all complex conditions in View.get method. and it can't
be reuse.
What do you say?
2013年1月2日水曜日 19時18分40秒 UTC+9 Russell Keith-Magee:
>
> Hi Hiroki,
>
> Thanks for the suggestion, but I'm afraid I don't see the benefit of doing
> this as configuration, rather than something in the dispatched method
> itself. Using your gist as an example -- why should this be something
> defined in a custom dispatching configuration format, rather than simply
> defining:
>
> def get(self, request, *args, **kwargs):
> if kwargs.get('corn') == '1':
> return HttpResponse('pony with corn')
> return HttpResponse('pony')
>
> Using this approach, you can be explicit about what you want to do; a
> developer reading the code requires no special knowledge to understand how
> it works (it's just standard Python code); you don't need to wrap the
> predicate up in to a function; it allows for more complex logic that can't
> be expressed as a simple predicate; and at the end of the day, it's less
> code as well. What's the advantage to your proposed approach?
>
> Yours,
> Russ Magee %-)
>
> On Wed, Jan 2, 2013 at 6:09 PM, Hiroki Kiyohara
>
> > wrote:
>
>> Hello, and Happy new year, everyone.
>> Please listen to my proposal.
>>
>> I want django.views.generi.View.dispatch method to call methods in
>> consideration of some config.
>> For example, calling methods depending on the value of the request
>> parameter.
>>
>> So I wrote this commit:
>> https://github.com/hirokiky/django/commit/e3399495dca9a727568626f64e2fa276c2857da9
>>
>> Description of this implementation
>> ---
>> View.dispatch_config takes a dictonary. Keys of dispatch_config are HTTP
>> method name as target.
>> Values are `predicate` dictionary. Key of `predicate` is method name
>> which you want to call to. It's `receiver`.
>> And the value of `predicate` is `predicate function`. When the function
>> returns True, dispatch method calls `reciver`(target method).
>>
>> Since my English is not good, plead watch this Gist (for usage).
>> https://gist.github.com/4433362
>>
>> Solution I proposed may be not adequate. but I want dispatch method to
>> be more flexible.
>>
>> Thank you.
>>
>> --
>> 清原弘貴 (Hiroki KIYOHARA)
>> mail: hiro...@gmail.com
>> http://hirokiky.org/
>> @hirokiky
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> django-develop...@googlegroups.com .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/TT1tHEDkF0oJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Minor feature: Make TestCase pass the testcase instance to self.client's constructor
Hi, When creating self.client in TestCase, it would be very useful if the testcase instance was passed to the client. I'm using a replacement client class that does various validation checks, so wants to use assert* functions on TestCase, thus takes a testcase instance as a parameter at creation time. However this means it can't be used as the client_class attribute on TestCase, as this is instantiated with no parameters (https://github.com/django/django/blob/master/django/test/testcases.py#L475) There are work-arounds, but it feels to me like a reasonably generic requirement that a test client may want to refer to the test case it's being used with. I think the change can be made largely backwardly compatible by changing to: self.client = self.client_class(testcase=self) which would only break an existing replacement client class that had an __init__ method without **kwargs. I'm happy to code this up, but wanted to check for any objections first. Cheers, Malcolm -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/j2agzjXZajsJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
> A modern Django project is a collection of apps. Files are looked up under > conventional paths within apps. Modules (especially the settings module) > can live anywhere on $PYTHONPATH. Actually, there's not such thing as a > project root. > > For instance, instead of using TEMPLATE_DIRS, project-wide templates can > go into an "myproject" application. You need one anyway as soon as you > write a custom template tag or filter. > > There are two special cases that don't fit into apps: STATIC_ROOT and > MEDIA_ROOT. (Technically, there's ALLOWED_INCLUDE_ROOTS too, but it isn't > commonly used.) > You can't just say "there is a solution I use, that isn't codified or widely used but solves the problem" and then waive your hand and have the problem go away. TEMPLATE_DIRS, FIXTURES_DIRS, and STATIC_FILES_DIRS are equally special cases unless and until a "project app" is the codified way to do it. Best practice or not, PROJECT_PATH/DIR/ROOT/ETC is common practice to avoid boilerplate. Relative paths for TEMPLATE_DIRS (& others) via Os.Path.Join is a straightforward solution that provides a clean conceptual runway from development to production. Sure the project as a directory analogy isn't a perfect one, but it is a useful first order approximation. For local development, it's certainly fine to store the code in > /home/myproject, compile the static files in /home/myproject/static, and > uploading the media files in /home/myproject/media, and it's convenient to > express that with relative paths. But it's hardly a best practice in > production — at least, not until you've spent 30 seconds thinking about it. > > Django leaves it up to the developer to structure the settings for > different environments. This means we cannot provide a "development only" > settings template. > Django doesn't provide an easy way to distinguish between Dev and Produciton environments (which I think is a separate discussion), Agreed. However, a default that works for development with the information that "you shouldn't do this in production, here's a link to how you should" is far better than nothing. Especially when the nothing is going to lead to people searching for a solution to usually find the default that works for development without the caveat. The current setup gets people to the same "ok for dev" state with more work and less knowledge. I could get behind a proposal to have a "project app" but I'd want to flush out the implications -- right now I'm still +1 on PROJECT_PATH and +0 on "project app". T FWIW, this is a working draft of a default settings file I like that addresses most of these issues: https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py (would appreciate constructive criticism offline) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/tw2TfcglfAAJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
Hi,
On Wednesday, January 2, 2013 8:19:36 PM UTC+1, ted wrote:
>
> FWIW, this is a working draft of a default settings file I like that
> addresses most of these issues:
> https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py
> (would appreciate constructive criticism offline)
Luckily you can already use that due to --template support for
startproject, but here a few comments (Aside from still being violently -1
on it):
* local_settings is imo a bad pattern as they can't easily override
anything without copying it completely into the local_settings (think of
all the settings which are dicts like DATABASES and CACHES)
* Where does LOCAL_SETTINGS come from, are you supposed to set that in
your settings file to get locale_settings imported? Why, if local_settings
are there I want them imported, that is the point of local_settings.
* All the env configuration stuff is just scary and way to specific for a
useful default settings file
* You have way to much stuff in INSTALLED_APPS, most of it is completely
out of scope for a default settings file.
* that applib sys.path magic just makes me cry.
That all said, it's nice if that settings file fits you, but I surely
couldn't do anything with it. This is probably how I would do it (Talking
about a big monolithic project):
project/default_settings.py
test_settings.py
dev_settings.py
production_settings.py
then each of the settings files would do: "from project.default_settings
import *" and then customize stuff as needed (eg: INSTALLED_APPS +=
('debug_toolbar',)). This way all the settings files are clearly separated
and stay readable. Might not be best practices but that's how it works
quite well for me.
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/A9l9wk8xT40J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
To be clear, I'm not proposing the settings.py file from my github as a
django default. It is what works for me, provided for context.
Florian, the method you use for environment specific settings is one of the
two most common I saw in my survey: local_settings.py being the most
common. Again, best practice vs common practice I don't know.
But again, I'm not proposing my settings.py file as the default, just
provided for context.
T
On Wednesday, January 2, 2013 4:17:41 PM UTC-5, Florian Apolloner wrote:
>
> Hi,
>
> On Wednesday, January 2, 2013 8:19:36 PM UTC+1, ted wrote:
>>
>> FWIW, this is a working draft of a default settings file I like that
>> addresses most of these issues:
>> https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py
>> (would appreciate constructive criticism offline)
>
>
> Luckily you can already use that due to --template support for
> startproject, but here a few comments (Aside from still being violently -1
> on it):
>
> * local_settings is imo a bad pattern as they can't easily override
> anything without copying it completely into the local_settings (think of
> all the settings which are dicts like DATABASES and CACHES)
> * Where does LOCAL_SETTINGS come from, are you supposed to set that in
> your settings file to get locale_settings imported? Why, if local_settings
> are there I want them imported, that is the point of local_settings.
> * All the env configuration stuff is just scary and way to specific for a
> useful default settings file
> * You have way to much stuff in INSTALLED_APPS, most of it is completely
> out of scope for a default settings file.
> * that applib sys.path magic just makes me cry.
>
> That all said, it's nice if that settings file fits you, but I surely
> couldn't do anything with it. This is probably how I would do it (Talking
> about a big monolithic project):
> project/default_settings.py
> test_settings.py
> dev_settings.py
> production_settings.py
>
> then each of the settings files would do: "from project.default_settings
> import *" and then customize stuff as needed (eg: INSTALLED_APPS +=
> ('debug_toolbar',)). This way all the settings files are clearly separated
> and stay readable. Might not be best practices but that's how it works
> quite well for me.
>
> Cheers,
> Florian
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/13cCcVbWiYwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
Hi Ted, On Wednesday, January 2, 2013 10:26:10 PM UTC+1, ted wrote: > Florian, the method you use for environment specific settings is one of > the two most common I saw in my survey: local_settings.py being the most > common. Again, best practice vs common practice I don't know. > In my surveys it turned out to be this: people often use local_settings but once I showed them the benefits of "my" approach they quickly converted. But again, I'm not proposing my settings.py file as the default, just > provided for context. Oh, I misunderstood you there. Sorry! Regards, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/C_qjTbsIFTMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On 01/01/13 18:28, Aymeric Augustin wrote: > There are two special cases that don't fit into apps: STATIC_ROOT and > MEDIA_ROOT. (Technically, there's ALLOWED_INCLUDE_ROOTS too, but it > isn't commonly used.) > > Static files are collected from the apps into STATIC_ROOT that is > then served by the web server. To avoid accidentally leaking Python > code over the web, it's a good idea to keep this directory outside of > your source tree. > > Media files are written by the application server into MEDIA_ROOT. > It's a good idea to put them on a separate partition (DoS by filling > up / isn't fun), or at least in a directory outside of your source > tree, which must be read-only for the web server. > > For local development, it's certainly fine to store the code in > /home/myproject, compile the static files in /home/myproject/static, > and uploading the media files in /home/myproject/media, and it's > convenient to express that with relative paths. But it's hardly a > best practice in production — at least, not until you've spent 30 > seconds thinking about it. You are assuming here that use of relative paths and PROJECT_ROOT for media implies that you are putting your MEDIA_ROOT/STATIC_ROOT *inside* PROJECT_ROOT. But you don't have to. I often have the situation where I have multiple copies of a project on a machine - often 'staging' and 'production' on the same machine (e.g. shared hosting), and also for other reasons. I have a layout something like: /home /myuser /apps /foo_staging /src /static /media /foo_production /src /media /static /src is PROJECT_ROOT, and STATIC_ROOT and MEDIA_ROOT will be calculated relative to that. This system makes projects completely relocatable, and is a good use case for PROJECT_ROOT IMO. However, this isn't something that you could put into a default settings.py, because it assumes things about directory structure outside the project sources. Common opinion amongst core devs seems to be against PROJECT_ROOT. If we are consistent about that, we ought to be thinking about deprecating TEMPLATE_DIRS, STATICFILES_DIRS, django.template.loaders.filesystem.Loader, django.contrib.staticfiles.finders.FileSystemFinder etc., as mentioned by Shai. Luke -- A mosquito cried out in pain: "A chemist has poisoned my brain!" The cause of his sorrow was para-dichloro- diphenyltrichloroethane Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding configuration to View to dispatch to any methods.
On Thu, Jan 3, 2013 at 2:46 AM, Hiroki Kiyohara wrote:
> Hi, Russ.
>
> Thanks for your reply.That makes sense.I notice that the configuration of
> my suggestion is complex.
> We need to know what the configuration to take the value.It is necessary
> to re-consider the implementation.
>
> Advantage of my approach
> -
> My approaches enables to reuse the condition of the method calling (as
> `predicate function`).
> For example, considering to header's value, session value or
> request.is_secure.
> By dispatch_config, we can reuse these conditions.
> Yes, in the example, the condition (kwargs.get('corn') == '1') is used
> only one time.
>
> And more
> --
> Now the configuration takes one predicate function, however, thinking the
> further reusability,
> We can enable the configuration to get more than one function to call one
> method, like...
>
> dispatch_config = {'get': {'get_corn_1': (corn_predicate,),
>'get_corn_1_secure': (corn_predicate,
> secure_predicate)}
> }
>
>
> It is hard to write all complex conditions in View.get method. and it
> can't be reuse.
>
What do you say?
>
>
I say:
def get(self, request, *args, **kwargs):
if corn_predicate(request):
if secure_predicate(request):
return HttpResponse('secure pony with corn')
return HttpResponse('pony with corn')
return HttpResponse('pony')
If reuse of predicates is an issue for you, then by all means, reuse them.
That doesn't mean you need to invent a new, inefficient, and highly
restricted scheme for invoking those predicates.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Minor feature: Make TestCase pass the testcase instance to self.client's constructor
On Thu, Jan 3, 2013 at 1:56 AM, Malcolm Box wrote: > Hi, > > When creating self.client in TestCase, it would be very useful if the > testcase instance was passed to the client. > > I'm using a replacement client class that does various validation checks, > so wants to use assert* functions on TestCase, thus takes a testcase > instance as a parameter at creation time. However this means it can't be > used as the client_class attribute on TestCase, as this is instantiated > with no parameters ( > https://github.com/django/django/blob/master/django/test/testcases.py#L475 > ) > > There are work-arounds, but it feels to me like a reasonably generic > requirement that a test client may want to refer to the test case it's > being used with. I think the change can be made largely backwardly > compatible by changing to: > > self.client = self.client_class(testcase=self) > > which would only break an existing replacement client class that had an > __init__ method without **kwargs. > > I'm happy to code this up, but wanted to check for any objections first. > Personally, I'm suspicious of any "A owns B, but B knows about A" relationships. There are certainly occasions when they're required, but whenever they pop up, it's generally an indication of a set of interfaces that are closely coupled. In this case, I'm not sure I see why this coupling is required. A test case is a test case. A test client is a test client. Their concerns are completely separate (evidenced by the fact that you can have a test case without any client usage, and vice versa). I very much see the test client as a utility tool for the test case -- really not much more than a convenient factory for requests -- not an integral part of a test case. Your feature request seems to be stem entirely from the fact that you want to invoke assertions in the test client code itself -- something that you're doing because you've got a bunch of extensions in your test client. I'll leave it up to you to determine if this is the right approach for your own project, but I'm not convinced it's a general requirement that warrants binding the test client to the test case. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On Thu, Jan 3, 2013 at 8:17 AM, Florian Apolloner wrote:
> * local_settings is imo a bad pattern as they can't easily override
> anything without copying it completely into the local_settings (think of
> all the settings which are dicts like DATABASES and CACHES)
I use this way to allow variable changes:
try:
execfile('local_settings.py', globals(), locals())
except IOError:
pass
Mostly because I want in development: new apps, middlewares, so these are
possible:
INSTALLED_APPS += ('debug_toolbar', 'django_extensions', 'devserver')
MIDDLEWARE_CLASSES += ('debug_toolbar.middleware.DebugToolbarMiddleware',)
On the main topic, I'm in favor of PROJECT_ROOT settings, it's a common
practice, and isn't that bad, once in production it can be a mount point or
overwritten on local_settings.py
[],
--
Luciano Pacheco
blog.lucmult.com.br
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Adding configuration to View to dispatch to any methods.
Thank you, Russ.
I notice that It is exaggerated to change View.dispatch method.
My proposal can be implemented by inheriting View.
With reference to your opinion, I wrote this PredicateProcessView:
https://gist.github.com/4440994
Inheritin this View, We can benefit as well as my proposal.
This discussion was informative for me.
Thank you.
--
清原弘貴 (Hiroki KIYOHARA)
mail: hirok...@gmail.com
http://hirokiky.org/
@hirokiky
2013年1月3日木曜日 8時23分55秒 UTC+9 Russell Keith-Magee:
>
>
> On Thu, Jan 3, 2013 at 2:46 AM, Hiroki Kiyohara
>
> > wrote:
>
>> Hi, Russ.
>>
>> Thanks for your reply.That makes sense.I notice that the configuration of
>> my suggestion is complex.
>> We need to know what the configuration to take the value.It is necessary
>> to re-consider the implementation.
>>
>> Advantage of my approach
>> -
>> My approaches enables to reuse the condition of the method calling (as
>> `predicate function`).
>> For example, considering to header's value, session value or
>> request.is_secure.
>> By dispatch_config, we can reuse these conditions.
>> Yes, in the example, the condition (kwargs.get('corn') == '1') is used
>> only one time.
>>
>> And more
>> --
>> Now the configuration takes one predicate function, however, thinking the
>> further reusability,
>> We can enable the configuration to get more than one function to call one
>> method, like...
>>
>> dispatch_config = {'get': {'get_corn_1': (corn_predicate,),
>>
>>'get_corn_1_secure': (corn_predicate,
>> secure_predicate)}
>> }
>>
>>
>> It is hard to write all complex conditions in View.get method. and it
>> can't be reuse.
>>
>
> What do you say?
>>
>>
> I say:
>
> def get(self, request, *args, **kwargs):
>if corn_predicate(request):
> if secure_predicate(request):
> return HttpResponse('secure pony with corn')
> return HttpResponse('pony with corn')
>return HttpResponse('pony')
>
> If reuse of predicates is an issue for you, then by all means, reuse them.
> That doesn't mean you need to invent a new, inefficient, and highly
> restricted scheme for invoking those predicates.
>
> Yours,
> Russ Magee %-)
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/mzZYthQVMuEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Oracle testing bug (was Re: Oracle testing issue, looks like bug: Separate connections to same DB)
31.12.2012 14:18, Shai Berger kirjoitti: On Sunday 30 December 2012 21:54:52 Anssi Kääriäinen wrote: Seems like you are correct [...]. Please open a bug. For anyone interested that isn't on the new-bugs list, it's https://code.djangoproject.com/ticket/19542 For anyone else: my apologies for the noise. Shai. Can you please setup simple testcase to ease bugfixing? -- Jani Tiainen - Well planned is half done and a half done has been sufficient before... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
