A tiny proposal around flatpages app.

[Dannier Trinchet Almaguer]

Hi guys,

I would like to consult you about a thought that it has been hitting me for 
a while, it is simple but important from my view point. 

It is around contrib.flatpages app, specifically around get_flatpages 
template tag.

I know you've tried to keep very simple this app, on the basis of:

" A flatpage is a simple object with a URL, title and content. Use it for 
one-off, special-case pages, such as “About” or “Privacy Policy” pages, 
that you want to store in a database but for which you don’t want to 
develop a custom Django application. "

and what I'm thinking don't try to change it, as opposed to that, I'm 
trying to keep Django more close to the first point of the Design 
philosophies: "Loose coupling". 

The point is, get_flatpages tag can be used as follow:

{% get_flatpages as flatpages %}
{% get_flatpages for someuser as flatpages %}
{% get_flatpages '/about/' as about_pages %}
{% get_flatpages prefix as about_pages %}
{% get_flatpages '/about/' for someuser as about_pages %}


If I want to get specific page I need to do it via its url or a prefix, 
which is somewhat rough, because my template code become data dependant, I 
meant, if I change the url of certain flat page then it is neccesary to 
change my template code too.

so, why don't allowing pages to be referenced by a symbolic name?, 
something like an identifier to the page, addable through e.g. the 
'Advanced options' section, thus we could do something like this:

{% get_flatpages 'about' as about_pages %}

which is more fexible and less data dependant, don't you? 

Besh wishes,

-- 
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/-/rpenXiSr-JkJ.
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.

[ANNOUNCE] Django 1.5 release candidate available

[James Bennett]

1.5 is almost here!

Today marks the release candidate, which you can read about on the weblog:

https://www.djangoproject.com/weblog/2013/jan/04/15-rc-1/

Assuming no release-blocking bugs, Django 1.5 will be released next week.

-- 
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: Status of ticket #14087 - management commands in namespace packages

[Aaron Merriam]

bump.  Any chance we can get this looked at?

On Thursday, September 13, 2012 2:55:56 PM UTC-6, Aaron Merriam wrote:
>
> I'm curious if someone can shed some light on ticket #14087 (
> https://code.djangoproject.com/ticket/14087)
>
> It appears there is a pull request open on github to fix this issue (
> https://github.com/django/django/pull/178)
>
> This recently became a problem when we separated out a few apps into 
> individual packages under the same namespace and there doesn't appear to be 
> any sane way to monkeypatch around the issue.
>

-- 
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/-/EfZlfv-HnpUJ.
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

[Malcolm Box]

On Wednesday, January 2, 2013 11:58:04 PM UTC, Russell Keith-Magee wrote:

>
> 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. 
>
>
I don't disagree - and this feature wouldn't require any test client to 
care about the testcase. 

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

The general pattern I want to implement is have a test client that makes 
assertions about all the requests made during a set of tests. For example, 
it could check that every get() returned cache headers, or that 
content_type is always specified in responses. Or that the response has 
certain HTML, uses certain templates etc - ie all of the assertion testing 
goodness in django.test.TestCase.

My concrete use case is a JSONClient that adds a json_get / json_post 
methods which makes sure to setup content_type etc on the call, and then 
validates that what came back was valid JSON.

The simple, wrong way is to do:

def check_response(self, response):
   self.assertContains(response, )
   

def test():
   r = self.client.get(...)
   self.check_response(r)

but this is error prone, verbose etc etc. 

The right thing is that within a test suite, the get()/post() etc to do the 
checks for me - and so it should be possible to create a testclient that 
does this, and be able to use this testclient in various test suites.

Is there a simple, clean way to solve this that I'm missing?

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/-/LNtkPS3EcdsJ.
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.