Re: Composite key development

y, March 1, 2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote: >> >> Hi Julien, >> >> I will publish it very soon. >> >> Thanks >> >> On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote: >>> >>> Hi Asif, >>> >

Re: Composite key development

lementation, as I haven't had the time > and energy to look into it too much, but I can try to clarify some > aspects of what I did years ago. > > On Mon, Feb 27, 2017 at 11:10:55AM -0800, Julien Phalip wrote: > > Composite primary keys (GSoC) > > > > =

Re: Composite key development

Hi Asif, That sounds good. On first look I did have some reservations about some of the design details in the current DEP, especially around the observer pattern for data binding. But I’m going to have to dig deeper into the implementation to get a clearer idea. It’d be great if you could publish

Re: Composite key development

On Tuesday, November 29, 2016 at 4:10:38 AM UTC-8, Craig Kerstiens wrote: > > My company (Citus Data) is interested in sponsoring some Django work. In > particular work on support for composite primary keys. From what I > understand this wouldn't be the first time the work has been explored and

Re: Deprecate admindocs?

On Jul 25, 2013, at 5:29 AM, Aymeric Augustin wrote: > Hello, > > I'd like to deprecate admindocs. Here are my reasons: > > 1) It's called the "documentation generator", but it only operates on > docstrings. This promotes the idea that docstrings are appropriate > documentation, while the Py

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

Hi, On Jul 15, 2013, at 9:22 AM, Carl Meyer wrote: > On 07/14/2013 07:16 AM, Jannis Leidel wrote: >> Yeah, I can relate to that, it does to me, too. I think decoupling >> the file serving slightly from how the files got to the place they >> are served from, is a good first step. The common denom

Re: Ticket 19445

Hi Luke, On May 1, 2013, at 3:31 PM, Luke Plant wrote: > Hi all, > > Can I get some feedback on what to do about ticket 19445? > > https://code.djangoproject.com/ticket/19445 > > I have re-opened this ticket because I don't think it was addressed > satisfactorily. I apologise in advance that

Re: broken pipe issue with runserver #4444

On Dec 18, 2012, at 5:18 AM, Emil Stenström wrote: > On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote: > I'd rather see this be leaved as-is, since I haven't seen a single > report on these broken pipe 'issues'. > > Here's a report: > > I'm using PhantomJS (headless webkit browser)

Re: django.contrib.redirects customisation

On Nov 15, 2012, at 12:22 PM, Лебедев Илья wrote: > Recently I needed functionality just like in django.contrib.redirects - > redirects table, that can be edited in admin. I was sad to find out that its > strongly not configurable. For example, I dont need status 301, but need > something else

Re: Admin UI improvement - actions displayed as buttons rather than drop-down list

Hi Marijonas, I've left a comment in your ticket. The conversation can continue there. Thanks, Julien On Nov 4, 2012, at 8:15 AM, Marijonas Petrauskas wrote: > Yes, it's created by me. Sorry for not referencing it. > > > On Sun, Nov 4, 2012 at 2:06 PM, Łukasz Rekucki wrote: > Hi, > > Isn't

Re: Yak shaving the test framework on the way to pluggable user models (#3011)

On Aug 25, 2012, at 1:15 AM, Russell Keith-Magee wrote: > Hi all, > > So, I've been working on a Django branch [1] to implement the approach > to pluggable user models that was decided upon earlier this year [2] > > [1] https://github.com/freakboy3742/django/tree/t3011 > [2] https://code.django

Re: RFC: More class based views, take two

Hi Andy and Iván, On May 28, 2012, at 12:38 PM, Iván Raskovsky wrote: > Hi Andy, > > On Mon, May 28, 2012 at 7:30 AM, Andrew Ingram wrote: >> Hi Iván, >> >> I'd temporarily given up on getting extra_views into Django because of >> a blocking issue with pagination and formsets. >> >> Assuming

Re: Redesign of djangoproject.com?

Hi everyone, It's really exciting to see the community offering to help in this endeavor. I myself spent quite a bit of time last year driving a redesign effort for djangoproject.com, so I thought I'd share my work with you now while the momentum is picking up again. So, using some initial briefi

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

On Apr 11, 2012, at 11:44 AM, 3point2 wrote: > Julien, I'm not describing an edge case. Django will return an HTTP > 500 for ANY field lookup on a related model that is not in the > list_filter option. > > To test, simply create a model that has a ForeignKey to another model > and hook it up into

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

On Apr 10, 2012, at 4:34 AM, 3point2 wrote: > The admin site allows the use of certain query strings to filter > change list pages. The syntax follows queryset field lookups, for > example http://mysite.com/admin/myapp/mymodel/?field__exact=test. > Lookups that are not specified on the ModelAdmin'

Re: Feature request: read-only admin view

Hi, This feature has been discussed in the past on this mailing list (e.g., http://goo.gl/ezMpc and more recently: http://goo.gl/j1CPv). There has also been talks about merging the databrowse contrib app into the admin (see this ticket: https://code.djangoproject.com/ticket/8936 or the GSoC propos

Re: Message Formatting in AdminMailHandler

Hi, On 27 October 2011 22:47, momo2k wrote: > Hello, > > I posted this question some time ago on django-users, but since nobody > answered and I think about this as a serious problem, I'll post here: > > Is there a reason why AdminMailHandler does not use > record.getMessage() as all other forma

Re: Proposal for a new templatetag definition syntax

On 13 October 2011 15:30, LeeS wrote: > Not sure if this is still an ongoing discussion, but I prefer to write > all new tags with a simple syntax that matches Python. There's no > real advantage in defining a unique, custom syntax for a template > tag. > > All HTML authors are already familiar

Re: Splitting out admin functionality

On 11 October 2011 14:04, tWoolie wrote: > > Yep. Could you outline your plan of attack for this? > > 1) create "newadmin" project to be a dropin replacement for admin. >(Clone current admin and slowly replace features/trim dead code) > > 2) Split out filterspec functionality into newadmin.fil

Re: Splitting out admin functionality

On 11 October 2011 12:22, tWoolie wrote: > > If someone is willing to take this on then I'd be happy to provide some > > support by reviewing patches, giving feedback etc. > > Cheers. Would you be willing to review code that swaps out entire > swathes of admin functionality? Yep. Could you outli

Re: Splitting out admin functionality

Hi, On 10 October 2011 15:20, tWoolie wrote: > I'd like to propose a project to split out the table/list > functionality and the filtering functionality in the django admin into > a seperate contrib app. This is really core functionality which is > lacking from django (in terms of being locked to

jQuery.noConflict() vs. jQuery.noConflict(true)

Hi, During the recent DjangoCon sprints there have been some discussions between Jannis, Rob Hudson and I around a change which occurred in trunk a few months ago in r16415 [1]. This change specifically made the admin use jQuery.noConflict() instead of jQuery.noConflict(true) while namespacing its

Re: confusing things in Trac UI (was: Design decision for #1625...)

On 20 September 2011 14:16, Carl Meyer wrote: > On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote: > > Well, I meant to mark accepted as endorsement of the patch, but that > > made me owner. > > Yeah, this is confusing in our Trac UI. The "accept" radio button at the > bottom assigns

Re: filter_horizontal back button issue under webkit

Hi John, On 9 September 2011 11:28, John wrote: > Hi All, > > This is in regards to ticket #13614 (Back button breaks many to many > widget). I'm hoping that bringing this up might bring some attention > to it. This is a rather nasty bug affecting the filter horizontal > widget's use with webk

Re: Browser Support

On 30 August 2011 19:08, Julien Phalip wrote: > ... perhaps the FAQ? > That is, assuming we'd consider this a potentially frequently-asked question :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: Browser Support

On 30 August 2011 17:33, Idan Gazit wrote: > So, a while back, I announced that Django is dropping support for IE6 in > the admin. What I _didn't_ specify is what browsers are supported. > > I'm currently composing a bit for the 1.4 release notes about admin browser > support, and wanted to expli

Re: What is Django?

On 26 August 2011 07:55, Amirouche Boubekki wrote: > 2011/8/25 Mikhail Korobov > > >> There are many big and well-known sites built with django and I think >> mentioning these sites and providing testimonials from people working on >> these sites can be better advertisement. >> > > Yes and no. Ad

Re: MultipleObjectMixin and Pagination

Hi Andrew, On Jul 1, 9:12 am, Andrew Ingram wrote: > Hi All, > > I've been working with Django's class-based views a fair bit recently, > specifically to create some additional ones (dealing with formsets > mostly). I've been trying to inherit as much of the existing > functionality as possible,

Re: Additional example for reverse_lazy documentation

Hi Alasdair, On Jun 30, 7:49 am, Alasdair Nicol wrote: > Hi, > > I like the upcoming reverse_lazy in Django 1.4 (commit 16121). I suggest > the examples should include using reverse_lazy in urlpatterns. > > I just helped a user out in stackoverflow [1] who was struggling with > NoReverseMatch err

Re: Javascript Testing

Hi Sean, On Jun 18, 4:24 am, Sean Bleier wrote: > Hello everyone, > > A couple months ago I started work on a django branch [1] (with the help of > @jezdez) that introduces a framework for writing javascript unit tests using > QUnit[2].  I started with QUnit because Django already included jQuery

Re: 5-for-1?

On Jun 18, 11:38 am, Stephen Burrows wrote: > I would love it if someone could look at 13956 [1] RFC'd, thanks ;) Julien -- 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.

Re: Logging configuration and handle_uncaught_exception

On Jun 17, 10:48 pm, Matt Bennett wrote: > > This is a case for a custom Filter object [1]. The filter object > > implementation would only be a few lines, to reject logging when DEBUG > > is True, and can be attached to the admin email handler in the default > > logging configuration. [2] This wa

Re: FYI: added a proper "easy" field to Trac

On Jun 16, 10:32 am, Julien Phalip wrote: > On Jun 16, 3:08 am, Alex Kamedov wrote: > > > Django documentation page Contributing to Django [1] has the same problem > > too > > [1]https://docs.djangoproject.com/en/1.3/internals/contributing/ > > I've fixed th

Re: FYI: added a proper "easy" field to Trac

On Jun 16, 3:08 am, Alex Kamedov wrote: > Django documentation page Contributing to Django [1] has the same problem > too > [1]https://docs.djangoproject.com/en/1.3/internals/contributing/ I've fixed the link in the wiki page. The doc is already fixed in trunk. Thanks, Julien -- You received

Re: Sorting UX question

On Jun 9, 9:45 am, Luke Plant wrote: > In the new admin sorting UI, which now supports sorting on multiple > fields, the behaviour can be described by the following two rules: > > 1. If you click on a header, it is made the primary sort field >    (with others moved down the list as necessary). >

Re: Proposal: Adding UI and UX fields to Trac

On Jun 8, 12:25 am, Luke Plant wrote: > On 07/06/11 11:32, Idan Gazit wrote: > > I'd like to propose adding two flags to Trac, "UI" and "UX". > So would it be better to have just "UI/UX"? I totally agree that Trac needs something specific for this, as it's a shame we have to remove admin-related

Re: Preventing the leaking of sensitive information in error logs

Many thanks to all for the feedback. I've just posted a new patch, welcoming any further feedback: https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff Regards, Julien -- You received this message because you are subscribed to the Google Groups "Django de

Re: Preventing the leaking of sensitive information in error logs

On Jun 1, 7:53 pm, Luke Plant wrote: > Would it possible to make the sensitive decorator add some kind of > strategy object to the request, which itself is responsible for the > filtering, rather than a simple boolean flag? The GET/POST parameters appearing in the error logs come from the HttpReq

Preventing the leaking of sensitive information in error logs

Hi, Recently I've been a bit embarrassed to receive a 500-error email report containing a client of mine's password displayed in clear because the admin login view had encountered an unhandled exception. This is probably OK in a debug environment but in production this can potentially have damagin

Re: Reshaping the "Contributing to Django" documentation

On May 21, 2:15 am, "Jonas H." wrote: > > "[...] try and duplicate it. If you can duplicate it [...]" > > I'd stick with "reproduce" here because "duplicate" may be confused with > "duplicate tickets". Yes that's a good point. I fixed that in the latest patch. Thanks! -- You received this messa

Re: Reshaping the "Contributing to Django" documentation

On May 21, 1:33 am, Waylan Limberg wrote: > One nitpick thought. I expect that people reporting bugs will go to > the "bugs-and-features" page, which is fine. However, as is often the > case, when their ticket is marked "accepted" (or some other triage > stage) they often get confused about what t

Reshaping the "Contributing to Django" documentation

Hi there, I've been working on reshaping the documentation about contributing to Django, in particular the rather dense historical page [1] and the excellent recently added how-to guide [2]. This documentation has sort of grown organically over the years and has become a bit difficult to read, so

Re: model fields options

On May 7, 2:21 am, Alex Gaynor wrote: > Sounds like a bad idea to me.  unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields.  All the other options belond to specific fields. I agree in principle, however I've

Re: PatchHammer 40,000

On May 6, 8:25 am, Luke Plant wrote: > I do think this could be useful though. If someone submits a patch that > *immediately* doesn't apply to trunk, then it will be useful to know > that, and hooking this in to Trac at the point the patch is uploaded > would be useful. On a related note, it wou

Re: Make redirection customizable in ModelAdmin view

On May 4, 4:13 pm, Yishai Beeri wrote: > +1 on breaking backwards compatibility, defaulting the arg to None. Just a note. Defaulting to None in itself does not break compatibility. Defaulting to None allows to do the url reversal from inside response_add. But then the tradeoff of preserving backw

Re: Make redirection customizable in ModelAdmin view

On May 4, 10:59 am, Dario Ocles wrote: > Hello everybody. > > Ramiro Morales and me were working on this ticket #15294 [0] and > Julien linked this one #8001 [1]. We had a little discussion about two > possible solution for #8001 and Julien suggested that we should hear > your opinion (you can rea

Re: NoSQL support

On Apr 28, 4:59 pm, Russell Keith-Magee wrote: > I haven't used the django-nonrel branch, and I'm not aware of anyone that > I know and trust that has. For what it's worth, I am currently using django-nonrel and its companions djangoappengine, djangotoolbox, and django-dbindexer [1] in a project

A coupla patch reviews

Hi there, I've just posted a patch for #14262 to add a new assignment_tag helper function. Is anyone keen to review it? Also, it would be great if someone could review the latest patch for #15805. If that one gets checked in then we'll also be able to fix #14608 and then I'll start work on #15838

Re: Request for comments: custom admin filters

On Apr 14, 8:46 am, Julien Phalip wrote: > Thanks a lot for your feedback. I agree with all your points and have > made the corresponding amendments in a new > patch:http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filt... Sorry, just in case you've already started

Re: Request for comments: custom admin filters

On Apr 14, 3:11 am, Jacob Kaplan-Moss wrote: > Hi Julien -- > > Thanks for your work on this! I'm working my way through the patch, > and it's looking good. I'm pretty happy with the internals, though I > do have some questions about the public API: > > * I'm rather unhappy with the `SimpleListFil

Re: Request for comments: custom admin filters

Hi Mikhail, On Apr 14, 4:56 am, Mikhail Korobov wrote: > Will your patch simplify creating filters not based on choices? E.g. > min/max filters where exact minimun and maximum values can be entered > (using form with method=GET and input fields for values)? I want a > pony ;) No, this patch does

Request for comments: custom admin filters

Hello there, I've just posted a patch with a suggested implementation of custom admin filters: http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.3.diff I've written some pretty comprehensive tests and have also had a stab at writing some documentation. You should find

Re: Something wrong about AssertRaisesRegexp and assertFieldOutput

On Apr 12, 2:00 pm, Karen Tracey wrote: > Adding re.escape in that function does break some tests, from a quick look > it seems mostly ones that are raising multiple errors but only one has been > listed by the caller of that utility function. It isn't clear to me from the > docstring of that util

Something wrong about AssertRaisesRegexp and assertFieldOutput

Hi, I've found two similar (and potentially linked) weird problems in the test framework while trying to understand why the perfectly looking tests in #14608 were failing. Before I open some tickets I'd like to hear if anybody has any clue about what's going on or if I'm missing anything. 1) asse

Re: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

On Apr 6, 12:09 am, Matt Hoskins wrote: > My apologies for reposting this - I originally posted this at the end > of January and as soon as I posted it I realised that with the push > for bug squashing for the 1.3 release going on I probably wouldn't get > any attention (and thus comment or replie

Re: Proposal: switch to HTML5 for bundled templates

FYI, I've just stumbled on ticket #7452 and this thread: http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/ One interesting idea that was suggested is to introduce a setting for controlling the type of HTML. -- You received this message because you are subscr

Re: Suggestion: a new "nature" field in Trac

On Apr 1, 10:36 am, Russell Keith-Magee wrote: > On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee > > wrote: > > Barring objection, I'll try to find some time this afternoon to > > introduce the new flags. > > A little later than originally intended... but I've just made these changes. > > La

Re: Suggestion: a new "nature" field in Trac

On Apr 1, 10:36 am, Russell Keith-Magee wrote: > On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee > > wrote: > > Barring objection, I'll try to find some time this afternoon to > > introduce the new flags. > > A little later than originally intended... but I've just made these changes. > > La

Re: Suggestion: a new "nature" field in Trac

On 29 March 2011 22:42, Luke Plant wrote: > As for the gardening, there are about 1700 open tickets that need the > type setting. Those needing the severity field changing to 'Blocker' can > be found more easily here: > > > http://code.djangoproject.com/query?status=assigned&status=new&status=reo

Re: Trac components cleanup

On Mar 29, 4:47 pm, Gabriel Hurley wrote: > The component re-organization is done now, as per Julien's (and Jannis') > suggestions above. I even re-categorized the 84 tickets that were in > "Contrib apps" into their new separate contrib.foo components (thank god for > Trac bulk modify privileges!)

Re: Proposal: switch to HTML5 for bundled templates

On Mar 29, 4:01 pm, Stephen Burrows wrote: > 3. There is a simple workaround going back to ie6 for handling the css > problems related to unrecognized tags. [3] ...snip... > [3]http://diveintohtml5.org/semantics.html#unknown-elements The workaround works if javascript is enabled. So we can't co

Re: Proposal: switch to HTML5 for bundled templates

On Mar 29, 2:29 pm, Julien Phalip wrote: > On Mar 29, 1:26 pm, Luke Plant wrote: > > > The further enhancements I'm thinking of are things like an EmailInput > > widget (which I'd suggest was the default widget for EmailField, but > > could be just available

Re: Proposal: switch to HTML5 for bundled templates

On Mar 29, 1:26 pm, Luke Plant wrote: > The further enhancements I'm thinking of are things like an EmailInput > widget (which I'd suggest was the default widget for EmailField, but > could be just available in django/forms/widgets.py). This widget would > output .  AFAIK, this is fully backwards

Trac milestones

Hi, Since we've recently been discussing a few ways to improve Trac, I'm suggesting to move the discussion which started a few minutes ago in #5833 here so as not to pollute the ticket with too many meta conversations. I'd also like to apologise for the confusion I seem to have stirred by changing

Re: Trac components cleanup

On Mar 29, 8:58 am, Gabriel Hurley wrote: > I can work on it late tonight (about 6-8 hours from now) if no one else gets > to it. > > All the best, > >     - Gabriel Excellent, thank you Gabriel! There's no rush -- whenever it suits you. Let me know if I can help in any way. Julien -- You rece

Re: Trac components cleanup

On Mar 29, 2:01 am, Jacob Kaplan-Moss wrote: > On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote: > > Now that 1.3 has been released (yay!), I'm reviving this thread to see > > if we can make Trac a little more efficient on our way to 1.4. I'll > > try to sum

Re: Suggestion: a new "nature" field in Trac

On Mar 28, 10:49 pm, Karen Tracey wrote: > +1 on having a distinction between bug, feature, and optimization. > > I don't think both "Uncategorized" and "Other" are necessary. My reasoning for "Other" was that there might be things that are neither a bug, a feature or an optimisation. I admit tha

Re: Suggestion: a new "nature" field in Trac

On 28 March 2011 17:28, Russell Keith-Magee wrote: > > * Uncategorized (default) > > * Feature request: for adding something new. > > * Bug report: for when an existing thing is broken or not behaving as > > expected. > > * Optimisation: for when an existing thing is not broken but could be > > m

Re: Suggestion: a new "nature" field in Trac

Hello, I'm not sure if the consensus so far is either "Meh" or "Let's give it a try", or if there's even a consensus. I'm still keen on the idea but I don't want to insist too much if it doesn't gather enough support, so I'll re-submit it here one last time. The latest proposal is to introduce a n

Re: Trac components cleanup

Hi all, Now that 1.3 has been released (yay!), I'm reviving this thread to see if we can make Trac a little more efficient on our way to 1.4. I'll try to summarise what's been suggested so far in regard to improving and clarifying the "Component" field: * The "Contrib apps" component would be mad

Re: Trac components cleanup

On Feb 28, 10:58 am, Paul McMillan wrote: > I think the django-admin.py categories could be consolidated into a single > one. > > In the interest of readability, we might rename django.contrib.foo to > simply contrib.foo. > > As long as we're clarifying, "Django Web Site" might be better named >

Re: Suggestion: a new "nature" field in Trac

> On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip wrote: > > Hello, > > > I was wondering if others would find it useful to introduce a new > > field in Trac to characterise the nature of a ticket, allowing to > > choose from at least: "bug report", "fe

Trac components cleanup

Hi, Tweaking Trac seems to be in the air, so I had some more ideas to suggest :) The "component" field in Trac is very useful when people look for tickets in their areas of familiarity/expertise. I think there are a few things that should be cleaned up to make the system a bit more useful and eff

Re: "needsinfo": resolution vs. triage stage

On Feb 24, 7:17 pm, Gabriel Hurley wrote: > In regards to #14702 , which so > far has been a universally favored idea, there's one lingering issue: > > Do we want to implement it as a resolution (i.e. you close a ticket as > "needsinfo" and the reporter

Re: Suggestion: a new "nature" field in Trac

On Feb 22, 3:22 am, Russell Keith-Magee wrote: > On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip wrote: > > I know there already is a "Has patch" flag, but I actually find that > > one a bit useless since there's no way to distinguish from the mass of > >

Re: Suggestion: a new "nature" field in Trac

On Feb 21, 4:35 pm, Gabriel Hurley wrote: > I'm still in favor of adding the "needsinfo" resolution and would love to > see that happen... I guess technically I could even do that one myself via > Trac's web admin if we're all agreed on it. I agree this is a good idea. By the way, for reference i

Suggestion: a new "nature" field in Trac

Hello, I was wondering if others would find it useful to introduce a new field in Trac to characterise the nature of a ticket, allowing to choose from at least: "bug report", "feature request", or "optimisation". I think this would help bring the right focus during alpha and beta stages, and also

Re: Enabling context access in simple_tag

On Dec 15, 10:52 pm, Russell Keith-Magee wrote: > On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip wrote: > > On Dec 14, 7:34 pm, Christian Hammond wrote: > >> On Dec 14, 12:02 am, Julien Phalip wrote: > > >> > On Dec 13, 10:16 am, Tai Lee wrote: > > >

Re: Enabling context access in simple_tag

On Dec 14, 7:34 pm, Christian Hammond wrote: > On Dec 14, 12:02 am, Julien Phalip wrote: > > > > On Dec 13, 10:16 am, Tai Lee wrote: > > > -snip- > > > > One suggestion from #1105 was to split out this functionality into > > > individual decorator

Re: Enabling context access in simple_tag

On Dec 13, 10:16 am, Tai Lee wrote: -snip- > One suggestion from #1105 was to split out this functionality into > individual decorators, @takes_context, @takes_block. I'm not sure how > easy this would be technically to implement, but I think it would > solve the `takes_context_plus` sink proble

Enabling context access in simple_tag

Hello, I'd like to bring up an itch that I've been desperate to scratch since my very early days with Django: the inability to access the context from a simple_tag. There are especially two use cases which I encounter on a near weekly- basis: (a) Generate a simple string or some very concise htm

Re: Tests for generic views' pagination

On Jul 6, 5:54 pm, Russell Keith-Magee wrote: > On Tue, Jul 6, 2010 at 1:43 PM, Julien Phalip wrote: > > Hi, > > > I'm starting to work on ticket #2367 ("Pagination for date based > > generic views" -http://code.djangoproject.com/ticket/2367) and I'm &

Tests for generic views' pagination

Hi, I'm starting to work on ticket #2367 ("Pagination for date based generic views" - http://code.djangoproject.com/ticket/2367) and I'm looking into the object_list generic view as a reference. For the life of me I cannot find any tests for object_list's pagination. Am I missing something or are

Introducing a CACHE_MIDDLEWARE_KEY_PREFIX-like setting for all cacheing operations (#12831)

Hi, Several people have expressed interest in ticket #12831, which has also been marked as DDN. So I thought the next step would be to bring it up on this list - let me know if that's not the right thing to do. Basically, I think that it would make sense and that it would be very useful if a new

Re: admin reuse

On Aug 15, 9:14 pm, Russell Keith-Magee wrote: > On Sat, Aug 15, 2009 at 3:52 PM, Haroldo > > Stenger wrote: > >  I've seen the admin evolve to very sophisticated user interaction. > > Nonetheless, the param to  HttpResponse() when a model object has been > > saved, is hardcoded and most of the t

Re: Call for ideas: Admin Improvements

On Mar 31, 6:53 pm, zain 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 reference

Re: Unified access to response.context in test client (follow-up)

On Mar 12, 11:10 pm, Russell Keith-Magee wrote: > On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip wrote: > > > On Mar 12, 9:30 pm, Russell Keith-Magee > > wrote: > >> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip wrote: > > >> > Hi, > > >

Re: Unified access to response.context in test client (follow-up)

On Mar 12, 9:30 pm, Russell Keith-Magee wrote: > On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip wrote: > > > Hi, > > > A few months ago James raised the issue on this list: > >http://groups.google.com/group/django-developers/browse_thread/thread... > > &

Unified access to response.context in test client (follow-up)

Hi, A few months ago James raised the issue on this list: http://groups.google.com/group/django-developers/browse_thread/thread/1b10084ea969141e Basically, the type for the test client's response context is inconsistent. Sometimes it's a dictionary and other times it's a list of dictionaries, de

Re: reason for missing readline() in uploaded files?

On Feb 4, 3:12 am, Marty Alchin wrote: > I suppose I should probably weigh in over here. For those who don't > know, I worked on much of Django's file handling, refactoring > FileField, adding storage options and standardizing the File interface > across models, forms, storage and uploads. If the

Re: #9344 and policy for small bug reports

On Jan 23, 6:42 pm, Karen Tracey wrote: > On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip wrote: > > > Hi, > > > I just wanted to draw your attention to what appears to be a bug in > > Django: the 'tell()' proxy is missing from the Windows-specific >

Re: #9344 and policy for small bug reports

On Jan 23, 5:14 pm, Russell Keith-Magee wrote: > On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip wrote: > > > Now, I know that this is sort of an edge case, and I also know that > > there are more important and more urgent matters at this moment. But > > I'd be keen

#9344 and policy for small bug reports

Hi, I just wanted to draw your attention to what appears to be a bug in Django: the 'tell()' proxy is missing from the Windows-specific implementation of TemporaryFile. This causes Django to crash when manipulating the uploaded file with PIL, for example. Ticket #9344 contains a patch to fix that

Re: logout() method for custom authentication backends

On Dec 1, 11:07 pm, David Reynolds <[EMAIL PROTECTED]> wrote: > On 1 Dec 2008, at 11:49, David Reynolds wrote: > > I have a custom authentication backend that requires a method to be > > run to log out of the system.  It would be quite useful if there was a > > way > > to hook into the django.cont

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > Hi folks -- > > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > I'm going to be the stick in the mud and say

Re: 1.1 feature: unify access to response.context in test client

On Nov 9, 7:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > The Djangotestclient exposes theContextused to render the returned > response, so that unit tests can inspect thatContextand verify that > it contained what it was expected to contain. This is all well and > good, except that there is

Upgrading Trac?

I know that this is likely to be a tricky/boring task and that it is probably low-priority since we're on the way to 1.1, but I thought at least I'd ask: Is there any plan in the short/mid term to upgrade Trac? My personal itch is that the current version (0.10.4) doesn't allow email obfuscation.

Re: readlines + InMemoryUploadedFile

> Is there a reason why InMemoryUploadedFile does not proxy readlines as > well from StringIO? seems like it should (especially if using PIL > directly from the uploaded file) I can't see any reason, you may want to open a ticket. There seems to be a number of missing proxies. For example, 'tell(

Re: Declarative syntax for widgets in ModelForm

On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote: > > > Why not do something like this: > > > class MyForm(forms.ModelForm): > > class Meta: > > fields = { &

Re: Declarative syntax for widgets in ModelForm

On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote: > Why not do something like this: > > class MyForm(forms.ModelForm): > class Meta: > fields = { > 'text': forms.CharField(widget=forms.Textarea(), ...), > 'other_field': None, > } This syntax would

  1   2   >