On Oct 2, 10:32 pm, Russell Keith-Magee
wrote:
> I completely agree that we don't want to rush this. The upside is that
> if we *can* reach consensus, it isn't going to require a whole lot of
> code changes; We're arguing about how to architect the base class, but
> once we've got that sorted out
On Oct 4, 1:04 pm, Andrew Godwin wrote:
> On 04/10/10 17:28, legutierr wrote:
>
> > * First, treat data processing and retrieval as separable from
> > rendering. Create a bright line of separation between the two
> > conceptual elements of the view (data and rendering)
On Oct 5, 10:43 am, Jacob Kaplan-Moss wrote:
> > * Does django.views.generic.utils.coerce_put_post() indicate a change
> > that needs to be made in Django? (Is there an existing ticket for
> > this?)
>
> Yeah, this has been a wart in Django for a while -- Django doesn't
> really "get" PUT very we
On Oct 17, 11:58 am, Russell Keith-Magee
wrote:
> On Sat, Oct 16, 2010 at 12:45 AM, Russell Keith-Magee
>
> I should also be able to port the tutorial before I commit -- which,
> barring objection, I will do tomorrow night my time (about 24 hours
> from now). Speak now, etc etc.
>
> Yours,
> Rus
On Oct 17, 3:51 pm, Łukasz Rekucki wrote:
>
> Currently, you can override only how successful responses are
> rendered. I'm going to try to work on this on my branch, but I have a
> small problem: In number of places, views raise Http404 which then get
> rendered by the default 404 handler (whi
Thinking about it more, I think that the approach you took makes more
sense.
Regards,
Eduardo
On Oct 17, 7:49 pm, Russell Keith-Magee
wrote:
> On Mon, Oct 18, 2010 at 2:00 AM, legutierr wrote:
>
> > On Oct 17, 11:58 am, Russell Keith-Magee
> > wrote:
> >> On Sa
After having spoken briefly to Carl and Russell about in irc earlier
this week, I created a new ticket that addresses the issues raised in
this thread:
http://code.djangoproject.com/ticket/15089
Would anyone mind accepting it and giving feedback?
--
You received this message because you are sub
I have been researching changes required to implement this, and I
thought I would share one of the sticky points. Some of this is
relevant to Gabriel's recent post.
I have been reading through revisions 14141 [1] and 14142 [2], which
reversed some of the changes in revision 13980 [3], and I have
I have added an initial, incomplete patch to the ticket for anyone who
would like to comment on it:
http://code.djangoproject.com/ticket/15089
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-deve
To complement the above list of locations where
Site.objects.get_current is still in use, I have generated the
following list of locations in the code where settings.SITE_ID
continues to be in use:
$ grep -nr SITE_ID * | grep -v svn | grep -v pyc
conf/project_template/settings.py:39:SITE_ID = 1
co
Carl and I had a long discussion in IRC about all the issues he raises
above. I am still digesting that conversation, but there are some
things that already spring to mind.
1. I can see the merits of defining a SITE_BACKEND api that would
allow users to choose from different site-retrieval implem
I'm afraid that I can't help you with the specific problem that you
are describing, but I would like to recommend that you look at the
work that Waldemar Kornewald and Thomas Wanschik are doing with their
django-dbindexer:
http://www.allbuttonspressed.com/blog/django/joins-for-nosql-databases-via-
http://code.djangoproject.com/ticket/15610
I just stumbled upon this unusual and problematic behavior, and
thought that it might be worth a discussion. Details are in the
ticket.
Regards,
Ed Gutierrez
--
You received this message because you are subscribed to the Google Groups
"Django develop
I hope it's OK to copy the body of the ticket here, even if it is
redundant, in order to spur discussion. I'm willing to work on a
patch if there is a consensus as to the proper solution...
modelform.is_valid() fails to anticipate database integrity errors
when those errors involve any fields tha
Thanks for your response, Florian.
> > modelform.is_valid() fails to anticipate database integrity errors
> > when those errors involve any fields that are not part of that form
> > itself.
>
> That is wanted behaviour, eg consider my workflow:
>
> class SomeForm(ModelForm):
> class Meta:
>
The subject didn't make any sense.
--
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...@googleg
Hi Carl-
> With your proposed change, if I happen to have a FavoriteBirthdayPresent
> in the database for a given year with an empty "username" field, it
> would incorrectly prevent any user from creating their own
> FavoriteBirthdayPresent for that year.
>
> I'll readily admit that's a corner cas
Hi Carl-
> Hmm, that's interesting. I'm not super-enthused about the complexity
> there (Zen of Python: "if the implementation is hard to explain, it's a
> bad idea"), but I think you're right that it's feasible. Note that
> nullable fields would be ok to go ahead with (because NULL is not equal
>
+ 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 great to see their work recognized by
the core team, and to be
04/27/2011 02:02 PM, legutierr wrote:
>
> > Ok, I'll create a patch soon (with tests + documentation) that
> > hopefully works for you. I don't think it will be very complicated
> > implementation-wise, just a few additional lines, I think. With
> > regards to
I didn't link to where I uploded the patch. It is here:
http://code.djangoproject.com/ticket/13091
On Apr 28, 1:43 am, legutierr wrote:
> OK, I just uploaded a patch against trunk that should be consistent
> with this discussion. As I note in the ticket, I kept the tests from
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
ost, but I think that it needs to be said.
On Apr 28, 4:28 pm, Carl Meyer wrote:
> 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
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 0
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
teers here, including the core developers. I also have
to say that you have made yourself available in a very generous manner
of late; for that I am quite appreciative.
Regards,
Ed Gutierrez
On Apr 28, 8:34 pm, Carl Meyer wrote:
> Hi Eduardo,
>
> On 04/28/2011 06:36 PM, legutierr wrote:
> For reference, here's where we'd be in that case (I still prefer the
> context manager over the idea of two separate calls to something named
> "validate"):
>
> def my_view(request):
> form = MyModelForm(request.POST or None)
> try:
> with form.validate(tweak=True) as obj:
>
> There are plenty of other workarounds -- the easiest is to note the
> email field is optional and just create a RealUserEmail object with a
> OneToOne to User. Given that, a hacky workaround in Django itself just
> isn't going to happen. The right thing to do is to get the auth
> refactor done a
Hi Fabian,
Are there tests that isolate this functionality? If there are, I can
run them against 2.5 and 2.6 to give you some independent
verification.
If not, you should look into how to run the Django test suite, and
write some targeted tests.
Regards
Eduardo
On May 5, 3:07 am, Fabiant7t
> 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.
>
> Alex
You're probably right about this, but (while we are on the subje
> Did you guys consider providing a Document class that is entirely
> separate from models.Model?
>
> Technically speaking teaching the ORM non-relational tricks is of
> course possible but in reality the philosophy is entirely different
> and you need to plan for NoSQL from the very beginning. Tr
> Please don't get me wrong. I have worked with RDBMS for more than a
> decade but I alse use django-nonrel with MongoDB on a daily basis. I
> also think that the approach django-mongokit takes is much more
> natural for NoSQL data than just reusing the ORM. The ORM has no way
> to express complex
Hi Luke,
I actually faced a problem similar to this when I ported CBV from 1.3
to 1.2, and then tried to use the TemplateResponse with a couple of
middleware decorators that I created from some custom middleware
classes. If I recall properly, I was also having backwards
incompatibility problems w
> These features have the stated purpose of allowing a response to be
> altered by middleware or decorators. However, if a decorator causes the
> template to be rendered, then such alterations will not happen.
>
> This is a serious issue, because decorators like these are often applied
> on an ad-
34 matches
Mail list logo
