Re: Proposal: Signal connection via "my_app.MyModel"

[Dougal Matthews]

On 9 May 2012 22:14, Yo-Yo Ma  wrote:
> This would allow for better decoupling of code, as well as a far
> cleaner dependency graph.

The dependancy will still be there, the string containing the dotted path
would be a hard link. However, this will be hidden and a less obvious
dependancy than a normal Python import.

So, I'd be -1 as I don't see the advantage of this and rather it just adds
further complexity.

-- 
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: #17028 - diveintopython.org links now dead

[Dougal Matthews]

 Mirrors are appearing in a number of places for this and the html5 version. 
Its hard to know which are more likely to stick around. 

http://diveintopython3.ep.io/
https://github.com/diveintomark/diveintopython3

Dougal

-- 
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: Template Engine Compilation and Runtime Refactoring Progress

[Dougal Matthews]

On Thursday, 28 July 2011 at 09:43, Kevin Tran wrote:
> Has the repository been deleted? 
> https://github.com/mitsuhiko/django-template-compilation is giving me a 404.

Try here: https://github.com/mitsuhiko/templatetk

-- 
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 Error Display Page

[Dougal Matthews]

On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:

> What I'd really like is a stacktrace in a plain text in the html
> commentary ("") on the very top of the page.

+1

This would actually be very useful when debugging Ajax calls in browsers. I 
often find myself reading the HTML particularly in chrome where I think the 
only other option is to save the file and re-open it.

Dougal 

-- 
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: Proposal for inclusion of two additional default template tags.

[Dougal Matthews]

On Friday, 7 January 2011 at 16:11, Jonathan S wrote:

> ** And a {% decorate %} template tag:
> http://paste.pocoo.org/show/316593/
> 
> I think they are generic enough to be included.
> {% decorate %} implements a commonly used design pattern. (Also known
> by XAML programmers.) It avoids the need of having to split a template
> into a head.html and footer.html, which is a bad practice, because it
> separates matching opening and closing tags over two files.
> 
> 


Can you explain what advantage the decorate tag has over regular old template 
inheritance?
I don't think I've ever felt the need to use head.html and footer.html


Dougal


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Direction on #10899

[Dougal Matthews]

On Tuesday, 26 October 2010 at 01:24, Preston Timmons wrote:

Hi,Could one of the core devs take a look over #10899 and give 
someguidance on what the best step to take next is? Thanks.I'm not a core dev, 
but it looks like the patch is missing documentation and the code needs a 
review by somebody other than the original author.Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Dougal Matthews]

On 21 October 2010 13:41, Tobias McNulty  wrote:

>  is there another mailing list thread or wiki page somewhere that follows
> or summarizes the decisions that went into django.contrib.staticfiles?  I
> think pointing to the fact that such a process has already happened would
> also resolve a lot of the concerns in this thread.
>

I think you are looking for this;
http://groups.google.co.uk/group/django-developers/browse_thread/thread/b333c14f40acd22a/288a34cc41bb4395

I'm not sure if its documented or summarised anywhere.

Cheers,
Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Smart extends

[Dougal Matthews]

I can see one main use case. Front end developers and designers would be
able to extend templates without worrying about python code changes or doing
a full copy and paste of the original template (if they can find it.)

Dougal
 On 15 Oct 2010 14:10, "Andrew Godwin"  wrote:
> On 15/10/10 13:41, J. Pablo Martín Cobos wrote:
>> Hi,
>>
>> I'm a Django developer since more or less 3 years. Some time ago I had
>> the need for the extends templatetag to have more funcionality.
>>
>> The funcionality I mean is that a template can extends from "itself".
>> I'm going to try to explain it better, so I will put Django admin as
>> an example, although I needed it in others places. In many projects I
>> wanted to customize the admin site, I wanted to tiny modify the
>> change_list template or the change_form template, etc. I.E. like the
>> following:
>>
>> file:templates/admin/change_list.html
>>
>> {% extends "admin/change_list.html" %}
>>
>> {% block extrastyle %}
>> {{ block.super }}
>> 
>> {% endblock %}
>>
>>
>> {% block breadcrumbs %}
>> 
>> 
>> {% trans "My Project" %}
>> 
>> 
>> 
>> {{ app_label|capfirst }}
>> 
>> 
>> {{ cl.opts.verbose_name_plural|capfirst }}
>> 
>> {% endblock %}
>>
>>
>> To perform something like this, we should copy all the change_list
>> template (i.e. 100 lines of code), in order to add this two changes.
>> For this subject I created a google-code project [1], wich is working
>> in a little project of Universidad de Granada [2] succesfully.
>>
>> I wait for yours feedback, and I hope this could be usefull
>
> Hi Pablo,
>
> So, from what I can work out, this is a proposal for an {% extends %}
> tag which allows you to extend from the parent template of the same name
> (so it looks back in the list of possible templates, and picks the one
> that comes before yours, in your case inheriting from the admin version
> of the template with the same name?
>
> I'd like to know what sort of use cases you think this is necessary in -
> in the example you provide, admin/change_list.html, the recommended way
> of doing what you're doing would be to set change_list_template on the
> ModelAdmin class to point to a different template which itself inherits
> from admin/change_list.html, rather than having two with the same name,
> which could be potentially confusing.
>
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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: Any interest in adding a navigation helper to Django?

[Dougal Matthews]

On 26 August 2010 17:25, Yo-Yo Ma  wrote:

> I'm speaking about something like http://code.google.com/p/django-nav/
>
> One of the main issues I deal with when developing software with
> Django is that I need to create a new template for every view that
> changes navigation (e.g. tabs). The ability to generate some sort of a
> map that allows for sub-navigation to show up in it's proper place,
> and make active navigation links take on an active look and feel,
> without manually adding templates would be very helpful for me. Is
> there anyone else out their with this problem?
>

I didn't know about this particular project, so thanks I'll check it out.

I can see the problem, I've had it before - although its not been too much
of an issue. What advantages does this have being included in Django core?
It seems to be doing quite well as an external project. Is there something
in Django that is stopping it work well externally?

Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Trac issues review

[Dougal Matthews]

On 15 August 2010 17:09, Jeremy Dunck  wrote:

> On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com 
> wrote:
> > Hi Russell,
> >
> > On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee
> >  wrote:
> >> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com 
> wrote:
> >>> I had few useful thoughts about changing the way Django development
> >>> contributions gets accepted and committed -- but all I get from this
> >>> mailing list that all attempts to improve any process is just a waste
> >>> of time.
> >>
> >> That's not entirely fair.
> ...
>
> Sorry, I've missed some context here -- can someone point me to the
> beginning of this thread?


It was previously titled "#11834: colorized debug page. Assigned to buriy"

http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #11834: colorized debug page. Assigned to buriy

[Dougal Matthews]

On 12 August 2010 15:54, Thomas Guettler  wrote:

> Why not commit?
>

I don't know the exact reason but its missing a few things. There are no
tests or documentation and these are both required.

Reading through the comments there doesn't seem to be a final decision on
the colours and the latest patch allows for customisation of this but I
don't think that YAS (Yet Another Setting) will be a popular move.

Brining it up here might just be enough to get a designers eye on it for
that part at least.

Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Comet support in Django?

[Dougal Matthews]

On 9 July 2010 13:25, Yuval Adam  wrote:

> But what is the easiest way to do this? Shouldn't Django supply some
> wrapper for comet functionality?
>

I imagine this is really out of the scope of Django but I might be missing
something. I'm no expert and haven't done much more than read about comet -
I've seen this thought it looks straight forward.

http://www.rkblog.rk.edu.pl/w/p/django-and-comet/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Cleanup Signal

[Dougal Matthews]

On 2 July 2010 05:44, hcarvalhoalves  wrote:

> Besides that, I don't see the need for anything to integrate inside a
> single "clean" command. It's not like the management commands provided
> by Django are hooks, you can and should be making yours for each
> specific need.


I agree with this.

Maybe the actual problem here is that management commands (like template
tags) are a pain to write.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: www.djangoproject.com down?

[Dougal Matthews]

On 1 June 2010 08:23, Vinay Sajip  wrote:

> I've been having trouble accessing www.djangoproject.com recently,
> from here in the UK. Is this a known problem? Is the server down?
>
>
It's fine from here (Edinburgh) and I've not had any problems lately.

Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Low-Hanging Fruit

[Dougal Matthews]

On 19 April 2010 22:20, Don Guernsey  wrote:

> How do I sign up to help? Is there an overall schematic for how django
> works?


Overview of the process.
docs.djangoproject.com/en/dev/internals/contributing/

Signup for trac.
www.djangoproject.com/accounts/register/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: [GSoC] Making django.db usable outside Django

[Dougal Matthews]

On 12 March 2010 12:51, Yuvi Panda  wrote:

> I'm a CS student from India and am planning to apply for this year's GSoC
> to work on Django.
>
> My project idea is to rip out the Django ORM so it could be used outside
> django. django.db will be isolated (ie. dependencies on other parts of
> django will be cut or folded back into django.db), and packaged with a
> different name (perhaps djangoorm, to avoid conflict with django) so it can
> be used in other web frameworks, application servers, desktop apps, etc.
> I've already done some prelim work[1] cutting dependencies, and all the
> django.db related tests run successfully. This will make atleast one part of
> Django usable by a lot more people.
>
> I'm writing up a full proposal, but thought it would be a good idea to
> check with the developers.
>
> Thoughts?


I've used the Django ORM in a few projects that don't use anything else
(some where not even websites). I just included Django and left much of it
unused - it worked very well and was very easy to setup.

What advantage does your approach have over that? besides having a slightly
smaller dependency.

Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Can't search 1.1 documentation on djangoproject.com

[Dougal Matthews]

If you head to http://docs.djangoproject.com/en/1.1/ and type in 'settings'
(for example) into the search on the right you'll notice that all the
results link to docs.djangoproject.com/en/dev/ rather than /en/1.1/.

It seems then that 'latest' under the search input is the development
version and there isn't an option for 1.1? When looking at the results the
url still contains 1.1 to add to the confusion.

This could be confusing for people that aren't closely following the new
features and changes.

Hopefully I've not missed this somewhere, I searched and couldn't find a
ticket.

Cheers,
Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: template rendering problem plz look at this.

[Dougal Matthews]

The django-developers mailing list is for the discussion about
the development of django itself, not using django.

Please use the django-users mailing list and don't cross post between the
two.

Dougal



On 17 February 2010 09:26, chiranjeevi muttoju <
chiranjeevi.mutt...@gmail.com> wrote:

>
> Hi,
> Actually my aim is to load the iframe when i click my link(play) in
> facebook. i get the functionality working fine but the problem is after
> loading the iframe with desired content, it becomes blur.. I dont know what
> the problem is. please see the bellow screen short  .
>
> After clocking the play link i want to change the i frame content.. for
> this i'm calling one view function.
>
> play button href is: 
> Play 
>
> view deff:
> def play(request):
> content = {'baseUrl' : settings.FACEBOOK_URL}
> return direct_to_template(request,'play.html',content)
>
>
> functionality is working fine but i'm getting the blur screen on the top of
> actual page. if i click on that page it replacing the entire page. i dont
> know what is the error. if anybody know please help me. if any other
> information please ask me.
>
> --
> Thanks & Regards,
> Chiranjeevi.Muttoju
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?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-develop...@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: contrib.Auth

[Dougal Matthews]

On 9 February 2010 08:09, Harro  wrote:

> - Make email unique and username non-required on the model. That would
> make implementing something that authenticated by email a lot
> easier :)
>

For reference there are some good points here[1] on this topic started
by Hanne Moa.

I think ideally the user model would be as simple as only having an ID as we
shouldn't make assumptions about requirements for usernames, emails or even
passwords with the vast array of login options we have these days. The
backends can then extend this to create logins that are based on email,
username, oauth, openid etc. Essentially giving us an ID to tie things
together and relating different authentication methods for the same user.

Just some food for thought until 1.2 is out of the way and everybody is
feeling a bit more sover.

http://groups.google.com/group/django-developers/browse_thread/thread/c522f1e2bf01c3f7

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Refining Django admin look proposal

[Dougal Matthews]

On 6 February 2010 15:38, patrickk  wrote:
>
> let me add a note about the "contest": if it comes down to skinning
> the admin-interface, a contest is not needed from my point of view. if
> (one day), it´s easy to "skin" the admin-interface, different skins
> will evolve (e.g., grappelli). I think that it´s important to create
> the prerequisites for skinning first.


It seems to me that we really have two issues here to tackle. Both are being
discussed separately or together in this thread but I see them very
differently.

So just as a food for thought:

Firstly is the case of the current admin's look and feel becoming dated.
Like most projects it could be improved in numerous ways - from small
changes to a complete overhaul. I think it would be dangerous to change it
too much as there are a large number of apps that reply on the layout. So we
at least need a fallback to the current layout if possible.

The second and perhaps more important issue is highlighted well by Patrickk.
It would be good if the interface was easier to skin, modify or just plain
replace. I guess like everything else from database backends to email
backends the ideal solution would make it easier to have your own 'admin
backend'. This could then start a whole new surge of admin style variations
that could be similar in some ways to pluggable apps - these could then be
added to trunk over time if it makes sense, again in a similar way to
pluggable apps.

Dougal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Enhanced debug output colors: django code is green, user code is red.

[Dougal Matthews]

2009/11/2 Yuri Baburov 

>
> Hi All,
>
> Since you are discussing and applying different features,
>
> I think it's time to ask what do you think of the subj.
>
> It's at http://code.djangoproject.com/ticket/11834
>
> It adds some helpful color beauty to django 500 output.
>
> Sample pictures are here:
> http://code.djangoproject.com/attachment/ticket/11834/11834.png and
> http://code.djangoproject.com/attachment/ticket/11834/11834_2.png
>
> I'm not a designer, so feedback is highly appreciated
>


I really like this, I always scan the traceback looking for items with with
.virtualenv in the path so I can ignore them - its bugged me for a while.
This is clearly a better solution.

I'm no designer either but I perhapsit could do with a bit of attention from
one, I'm not that keen on the red (pink?) and green mix.

Also, documentation will be needed so users know what the colours mean but
I'm not sure where in the docs. I can't see anything on the current error
page.

Dougal

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Dougal Matthews]

2009/10/19 Jeff Anderson 

>
> An official "real-life", advanced tutorial would have been wonderful to
> fill
> the gap that I had. It would have saved me quite a bit of *re-learning*
> things,
> which is always annoying.
>

If you can outline some of the gaps you had and examples it might be useful
for somebody when tackling the content for this. A more advanced topic is
fine but as long as it covers the topics people learning consider to be
advanced or initially more difficult.

Dougal

--~--~-~--~~~---~--~~
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: Continuous Integration command

[Dougal Matthews]

2009/10/18 Dougal Matthews <douga...@gmail.com>
>
> It had been discussed recently;
> http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c?hl=en=gst=failed#c54aa0fd48ed7b8c
>

Link fail. This one will work better;
http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c

Dougal

--~--~-~--~~~---~--~~
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: Continuous Integration command

[Dougal Matthews]

2009/10/18 Anssi Kaariainen 
>
>
> Is it possible to autorun only the failing tests? It would be very
> useful (at least for me) if the following was supported
>

No. Not yet anyway...

It had been discussed recently;
http://groups.google.com/group/django-developers/browse_thread/thread/825b6a1b676f24ed/c54aa0fd48ed7b8c?hl=en=gst=failed#c54aa0fd48ed7b8c

--~--~-~--~~~---~--~~
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: Proposal for 1.2: Improved URL system

[Dougal Matthews]

2009/10/18 Maxim Penzin 

>
>  Another crazy idea for shorter object fetch is
> "/%(model_name.id)d/" or may be another syntax like "/%%(model_name)/"
> to get rid of
>  get_object_or_404( id=int(id) )
> at the first line of every view method.
>


I quite like this idea, not sure about that syntax exactly but the idea is
nice. Personally I'm a fan of regular expressions so wouldn't want to see
them removed or abstracted to a level that really isn't that different.

Something like this however would be more interesting as as you say it skips
a bit of code that ends up in many views. It could also be used pass the
view pre-filtered querysets. Say  for example with date based filters. i.e.
/2009/, /2009/09/ and /2009/09/09/ would go to the same view but rather than
pass the date or date parts the view is passed the result of a
Model.objects.filter()

However, I'm at a total loss of how the syntax for this would work :)

--~--~-~--~~~---~--~~
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 an option to re-test only failed tests

[Dougal Matthews]

2009/10/2 Javier Guerra 
>
>
> - if there's no 'failure record' run all
> - if there's some record, first test those that have failed the last time
>   - if they still fail, stop there
>   - if there's no further failures, rerun the whole set
>
>
+1, that sounds like a good approach to me.

--~--~-~--~~~---~--~~
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: Distorted layout of this group in Google Groups

[Dougal Matthews]

2009/9/21 Karen Tracey 

> On Mon, Sep 21, 2009 at 10:53 AM, Léon Dignòn wrote:
>
>>
>> Hello,
>>
>> Am I the only one with this problem? It's annoying because it covers
>> all the topics and also text of discussions.
>>
>>
> This appears to be some sort of google groups problem, that only affects
> some people some of the time (I've not seen it at all).  See:
>
>
> http://groups.google.com/group/is-something-broken/browse_thread/thread/c73ae586c6fcef48/
>
>
Funnily enough I seen the problem on that link itself but reloading the page
(F5) sorted it out for me.

Dougal

--~--~-~--~~~---~--~~
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: Looking for a project

[Dougal Matthews]

Daniel,

It would probably be worth you listing your ideas even if they are half
baked. This would show people what you are interested in and we could
possibly help you develop them further.

Otherwise, you could look at the wiki for discussed features or even get
involved in 1.2?

Dougal



2009/9/20 corn13r...@gmail.com 

> A django webmail app
>
> -- Sent from my Palm Pre
>
> --
> Daniel Watkins wrote:
>
>
> Hello all,
>
> As part of the third year of my computer science degree (at the
> University of Warwick), I need to complete an individual project. I'd
> quite like to use this to do something for Django. The project is meant
> to be done entirely individually, which means that something that works
> as a standalone app (rather than being a branch of Django itself) would
> be preferable.
>
> The project needs to be completed between the beginning of October and
> April, with about 5 hours a week being spent on it.
>
> I have a few half-formed ideas of my own, but if anyone else has an idea
> of what I could do, I'd like to hear about it.
>
>
> Cheers,
>
> Dan
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Dougal Matthews]

I'm a +1 for helping and doing whatever I can do improve the tutorials as I
think they could be expanded. However I'm about to bugger off for a month so
I'm not sure how that will fit in with timelines and such.

Dougal

2009/8/7 Jacob Kaplan-Moss 

>
> On Fri, Aug 7, 2009 at 11:19 AM, Rob Hudson wrote:
> > I'd be happy to help flesh out one or more of these.  This isn't
> > necessarily a 1.2 feature but would be a nice addition to the
> > documentation.
>
> I am *always* looking to improve the docs, so of course I'm an
> enthusiastic +1 on more tutorials. The hard part for me is always just
> getting a rough draft done, so as a general standing offer if you (or
> anyone) gets a rough draft banged out I'll happily act as co-author,
> editor, proofreader, or any combination.
>
> Jacob
>
> >
>

--~--~-~--~~~---~--~~
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: Why are checkboxes *still* like this?

[Dougal Matthews]

Create a patch?
Dougal


2009/7/26 judgej 

>
>
> http://code.djangoproject.com/browser/django/trunk/django/forms/widgets.py
> line 595:
> output.append(u'%s %s' % (label_for,
> rendered_cb, option_label))
>
> 1- I know there is argument in the CSS/designer community about
> embedding  tags inside  tags, or not.
>
> 2- But, its pretty clear that the usability of  checkboxes drive the
> "input first, label after"
>
> Which leads me to the question:
> Why is django hardcoding HTML snippets in code
> ... when its clear that either the snippet is wrong, or arguable?
>
> I'm left hard-coding form templates vs. trying to swapo-chango via
> CSS.
>
> Which leads me to question #2:
> What does django want me to do, or is this what I should be
> doing?
>
> -- joe
>
> >
>

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

[Dougal Matthews]

As I understand it; All of the 'real' tickets are fixed.
http://twitter.com/freakboy3742/status/2671770783

People are adding new tickets and assigning them to 1.1, because they can,
but these are generally being rejected or move to 1.2 I think. I'm not sure
when we will see 1.1 out the door but I think we are possibly waiting for
documentation and translations only?

But yeah, perhaps a beta or RC is needed?

Dougal

---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/



2009/7/21 Michael Kerrin <michael.ker...@gmail.com>

> Hi All,
>
> I am working on a project that is currently running Django 1.1Beta from
> March 23rd.
>
> I am enquiring about the road map for the Django 1.1 release as I have not
> seen much talk on the mailing list (I don't pay much attention to my IRC
> client so apologies if I miss discussions there).
>
> The last I heard about any road map was the blog posting
> http://www.djangoproject.com/weblog/2009/may/07/django-1-1-update/ on May
> 7th, which contains a linking (I won't post here as the link is long) to
> "the complete list" of open bugs. This "list" is constantly in flux. As of
> starting to write this mail a "new bug" was added to this list and the other
> bug wasn't there 2 weeks ago before I went on vacation.
>
> I understand the nature of open source which requires volunteers to donate
> their free time to the project and as such I really expect things to run a
> bit late. But I am getting very concerned that the last beta was 4 months
> ago, the road map at http://code.djangoproject.com/wiki/Version1.1Roadmapis 3 
> months past, there doesn't seem to be any end goals for the release and
> I am not seeing any communication about any of this as all public sources of
> information on this subject are just as old.
>
> As I said I currently use Django1.1 Beta. I think it is great. It contains
> some really good improvements especially in the ORM Aggregation and F
> expressions that made the project I am working considerable easier and the
> code cleaner and more fun to work on. But it is 4 months old and a beta.
>
> So I can please request / beg / ask nicely someone to update the roadmap.
> Even a new Beta release would reduce some of my concerns at the moment :-)
>
> Thanks
> Michael
> --
> Michael Kerrin
>
> >
>

--~--~-~--~~~---~--~~
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: Try out new inline features [GSoC admin-ui]

[Dougal Matthews]

I was just messing around with it and got this error;

http://dpaste.com/64095/

Not exactly sure what I did to cause it though.

Cheers,
Dougal


---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/



2009/7/7 patrickk <patr...@vonautomatisch.at>

>
> another more severe problem ... I´m going to stop writing after this
> one ;-)
>
> when adding items with stacked-inlines, every comment automatically
> gets a value for the order-field. this means, when I´m adding a
> comment (without entering anything) and click on "save" I´m getting an
> error. this obviously shouldn´t be the case ...
>
> thanks,
> patrick
>
>
> On 7 Jul., 13:12, patrickk <patr...@vonautomatisch.at> wrote:
> > more feedback to your inline-solution:
> > ### if you use a draghandler for stacked-inlines, there should be a
> > draghandler for tabular-inlines as well (instead of dragging the whole
> > row).
> > ### deleting stacked-inlines: not sure if the delete-button should be
> > displayed with the selectors (near the draghandler). if not, there
> > should at least be an indication on the left-hand side if (or if not)
> > something has been marked for deletion.
> > ### from my point of view, the representation of an original object
> > with tabuar-inlines is redundant. within  the
> > paragraph can be removed.
> >
> > css-stuff:
> > ### the comma seperated integer field has the class "vTextField". not
> > nice.
> > ### why has URLField the class "vURLField" and EmailField has the
> > class "vTextField". very inconsistent here.
> > ### IPAddressField again misses the class, the same for filepathfield
> > and so on ... I´m not going to list everyhing here since you probably
> > know what I mean. it´s currently very messy (sometimes there is a
> > class, sometimes not, sometimes the class doesn´t relate to the
> > field ...).
> >
> > ### I´d use a different class for _every_ field. most of the time, it
> > ´s the same as vTextField, but it makes customization so much easier.
> > and it´s clean and coherent.
> >
> > ### at the change-list, the save-button (if you have forms on the
> > list) is within the paginator. shouldn´t be there, from my point of
> > view.
> >
> > regards,
> > patrick
> >
> > On 7 Jul., 11:16, Zain Memon <z...@inzain.net> wrote:
> >
> > > Hey Patrick --
> >
> > > On Tue, Jul 7, 2009 at 1:04 AM, patrickk <patr...@vonautomatisch.at>
> wrote:
> >
> > > > [snip]
> >
> > > > there´s a lot more to say here, but I´m not sure if this is somehow
> > > > related to your work - not sure if you only work on the inline-stuff
> > > > or the admin-interface overall.
> >
> > > Both my GSoC project and future interests lie in improving the overall
> > > usability of the admin interface, so feel free to pitch away.
> >
> > > > besides the index-page, someone should take a look at the html/css.
> > > > the programming is a mess in certain places (e.g., every input-field
> > > > on the change-form has a class, but decimalfield and floatfield don
> > > > ´t). moreover, the naming of the css-classes doesn´t seem to be well
> > > > thought out.
> >
> > > I'll take a look at the decimalfield and floatfield classes. If there
> are
> > > other major inconsistencies, let me know and/or file a bug.
> >
> > > > something which is related to inlines: currently, with
> stacked-inlines
> > > > you´re having "comment #1 ...", "comment #2 ..." and so on on the
> left-
> > > > hand side. IMHO, you should display __unicode__ there (I hope you
> know
> > > > what I mean). because with 20 comments listed there, one has to click
> > > > through all items to actually see what´s in there ...
> > > > one more thing: it currently says "Add a choice" - I´m not sure if
> > > > this should be "Add a Choice" in order to be translated correctly.
> >
> > > It actually *is* the __unicode__ of the model -- I just happened to
> specify
> > > __unicode__ for comments as "Comment #%(id) @ %(time)".
> >
> > > All good stuff. Thanks!
> >
> > > Zain
> >
> >
> >
>

--~--~-~--~~~---~--~~
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: EuroPython Sprints

[Dougal Matthews]

I'm attending the conference. I'll be around on the Friday and would
like to meet up with fellow djangonaughts.

Looking here; http://www.europython.eu/talks/talk_abstracts/ there
seems to be a few djangonaughts going.

Just search the page for Django and you'll find the related talks ;)

Cheers,
Dougal


---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/




2009/5/19 Richard Boulton <boulton...@googlemail.com>:
>
> 2009/5/19 Sergio Oliveira <seo...@gmail.com>:
>> Is there someone going to EuroPython (Birmingham - UK)?
>> I've just saw that Django is in the top of the proposed sprints list:
>> http://wiki.europython.eu/Sprints
>
> I'll be at the conference, but won't be able to be around before /
> after for the proposed sprint days.  That said, if anyone would like
> to meet up during the core conference days to talk about Django-search
> integration (as in, full text search / advanced information retrieval
> features), I'd be keen to be included.
>
> --
> Richard
>
> >
>

--~--~-~--~~~---~--~~
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: Call for ideas: Admin Improvements

[Dougal Matthews]

   - Photo Management - crop, rotate (with ability to add more filters)
   - Make it easier for people to create custom themes and styles for the
   admin and change between them
   - Allow models to be added twice with two modeladmins serving a different
   process


---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/




2009/3/31 mrts <m...@mrts.pri.ee>:
>
> Add and remove instances to/from formsets with a button click is much
> needed instead of the current delete checkbox and `extra` handling
> (both for formsets in general and for admin formsets in particular).
> There is a snippet (that I've not tried) at
http://www.djangosnippets.org/snippets/1389/
> .
>
> On Mar 31, 10:53 am, zain <z...@inzain.net> wrote:
>> I'm applying for the GSoC with some thoughts to generally improve the
>> admin interface. So far, I have the following ideas:
>>
>> 1) An autocomplete widget
>> 2) Drag & Drop support for ordered relations
>> 3) Foreign Key traversal to see and modify models referenced to by
>> ForeignKeys inline
>> 4) Refactor the admin's Javascript to use JQuery for maintainability
>>
>> Do you have any other ideas for features and fixes to improve the
>> admin interface?
> >
>

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