On Thu, Apr 28, 2011 at 10:13 PM, Carl Meyer wrote:
> Hi all,
>
> We have a number of tickets open (at least #12028, #13249, #13091,
> #15326, and #15860 -- #13091 is the active one) reporting problems with
> unique_together constraints in our attempts to validate arbitrary
> partial models, when
Hi all,
We have a number of tickets open (at least #12028, #13249, #13091,
#15326, and #15860 -- #13091 is the active one) reporting problems with
unique_together constraints in our attempts to validate arbitrary
partial models, when validating a ModelForm with some fields excluded.
Eduardo Gutie
On 04/28/2011 07:12 PM, legutierr wrote:
> I'm up for working on the new idiom now. I've put this much time into
> it, I don't want to waste the momentum. What's the approach you are
> thinking of, and how can I get started in the implementation?
Much appreciated. I have a half-written post abou
Hi Eduardo,
On 04/28/2011 06:36 PM, legutierr wrote:
> This is extraordinarily discouraging.
I can understand why.
I've also spent a number of hours thinking about this, reviewing the
patch, considering alternatives, coming up with cases that might break,
etc. I'd like to set aside those sunk
Hi amagee-
Have you tried this?
base_a.html
first {% block content %}{% block subcontent %}{% endblock %}{%
endblock%} last
base_b.html
{% extends "base_a.html %}
{% block content %}left{% block subcontent %}{% endblock %}right{%
endblock %}
template.html
{% extends (either "base.a.html" or "ba
I'm up for working on the new idiom now. I've put this much time into
it, I don't want to waste the momentum. What's the approach you are
thinking of, and how can I get started in the implementation?
On Apr 28, 4:28 pm, Carl Meyer wrote:
> Hi Eduardo,
>
> On 04/28/2011 12:35 PM, legutierr wrot
I sometimes run into a situation where I want a template to be able to
extend from one of a set of possible base templates, which I achieve
by passing a "base_template" variable in the context to the {% extends
%} tag. Where this gets stuck, though, is if one of the possible
bases extends one of t
This is extraordinarily discouraging. This is the second time that I
have devoted tremendous energy to a patch, trying to coordinate with
core developers, not doing any work until I get the green light from
core developers regarding an implementation plan (trying to avoid this
very same eventualit
Hi,
let me introduce myself a bit before I start talking about my upcoming work
during the summer. My name is Gregor Müllegger and I was accepted as a Google
Summer of Code Student for Django, doing the project called "Revised form
rendering". Next Monday will start my fourth year at the universit
This seems to me like a problem best-solved by adding another attribute to
BaseDatabaseFeatures so that DBs which don't support infinity can fail
loudly, obviously, and preemptively. That make sense?
- Gabriel
--
You received this message because you are subscribed to the Google Groups
Hi Eduardo,
On 04/28/2011 12:35 PM, legutierr wrote:
> I just added a new patch in response to Carl's comments on the ticket.
>
> http://code.djangoproject.com/ticket/13091
So, in the process of reviewing and tweaking this patch for commit, I
checked in the #django-dev IRC channel for any other
I just added a new patch in response to Carl's comments on the ticket.
http://code.djangoproject.com/ticket/13091
Regards,
Eduardo
--
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@goo
On Thu, Apr 28, 2011 at 6:32 AM, Waldemar Kornewald
wrote:
> As suggested by Russell, I'll try to explain the reasoning behind
> every proposed change on the wiki page in the next few days.
That would be a huge help. I'm trying to wrap my brain around the
megadiff Jonas posted, but I'm having tro
On Thu, Apr 28, 2011 at 12:37 PM, Eric Florenzano wrote:
> On Apr 28, 2:36 am, "Jonas H." wrote:
>> For anyone who's interested, here's the complete diff of Django-nonrel
>> against Django 1.3:http://paste.pocoo.org/show/379546/
>
> Are you sure this diff is correct? From a quick look over that
On Apr 28, 2:36 am, "Jonas H." wrote:
> For anyone who's interested, here's the complete diff of Django-nonrel
> against Django 1.3:http://paste.pocoo.org/show/379546/
Are you sure this diff is correct? From a quick look over that diff,
it seems there's a bunch of seemingly unrelated changes in
On 04/28/2011 08:59 AM, Russell Keith-Magee wrote:
To be completely frank, from my perspective, the code is an unknown
quantity at this point. It *might* be fine -- but it might not, on
anything from a scale from "needs minor work" to "needs to be
rebuilt". I simply don't know, and any process th
Speaking of bottlenecks ... imho Waldemar and Thomas should be core
devs in addition to
the proposed process of getting more/better community review on Django-
nonrel before a merge into trunk can happen.
--
You received this message because you are subscribed to the Google Groups
"Django develo
Speaking of bottlenecks ... imho Waldemar and Thomas should be core
devs in addition to
the proposed process of getting more/better community review on Django-
nonrel before a merge into trunk can happen.
--
You received this message because you are subscribed to the Google Groups
"Django develo
Created two tickets.
http://code.djangoproject.com/ticket/15915
http://code.djangoproject.com/ticket/15916
The latter seems a bit vague to me. I'm thinking about creating some
specific tickets and patches to provide better console experience :-)
If it's a noble goal, and there weren't huge discu
On Thu, Apr 28, 2011 at 3:18 AM, legutierr wrote:
> + 100 on this (oh, wait, do I not get that many votes? +10 then).
>
> Waldemar and Thomas (and the rest of the people contributing to django-
> nonrel) have worked very hard to advance Django and expand its use
> into new spheres. It would be gr
20 matches
Mail list logo
