Hi Alex,
On Jun 7, 9:35 pm, Alex Gaynor wrote:
> As you can see the fruits of these efforts have already begun to land
> in my branch, and I suspect that the multidb refactorings of last year
> have left us in a better state than I appreciated: while the concepts
> and data structures used in the
Hi, Marco
Do You use symfony?
On Jun 7, 1:03 pm, Marco Louro wrote:
> Hi all,
>
> I'd like to propose adding a tag that includes a template with clean
> context, but can accept parameters that will be added to that
> context.
>
> The use-cases are plenty, but I've been using it mostly with forms
Hello...
Modular or divided is not so good as You can feel it now, I think...
For example second web framework I use is symfony. And I hate it
because of this as You say "modularity".
While developing big project I have more then 50 open buffers in emacs
only, plus gvim buffers, plus console window
Gabriel,
I only made that decision because I didn't see the need to have whole
context, and the only time I have needed it was because of the {%
csrf_token %}. This is just my use-case, but I understand that other
people might want to use it differently. I don't think it makes much
of a difference
I've now had to learn this the hard way by having real live data
deleted from my database on two production projects and it pisses me
off big time every time.
I can accept that NOT nullable foreign relations cascade the delete
but not if they have null=True on them. Example:
class Survey(Models):
Hi,
I think this is the related ticket:
http://code.djangoproject.com/ticket/7539 "Add ON DELETE and ON UPDATE support
to Django"
Me and a lot of other people are on the cc list of this ticket.
Peter Bengtsson wrote:
> I've now had to learn this the hard way by having real live data
> deleted
I'm +1 on the optional "with" parameter for {% include %}. -1 on
adding a new tag for this.
I also use {% with %}{% include %} a lot in templates but we should
follow with/blocktrans syntax for consistency:
{% include "part.html" with obj.title|capfirst as title and "large"
as main_class %}
A
On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald wrote:
> Hi Alex,
>
> On Jun 7, 9:35 pm, Alex Gaynor wrote:
>> As you can see the fruits of these efforts have already begun to land
>> in my branch, and I suspect that the multidb refactorings of last year
>> have left us in a better state than
On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson wrote:
> I've now had to learn this the hard way by having real live data
> deleted from my database on two production projects and it pisses me
> off big time every time.
>
> I can accept that NOT nullable foreign relations cascade the delete
> but
On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor wrote:
> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald
> wrote:
>> Why did you revert the AutoField patch? BTW, in the Django-nonrel
>> patch you'll find a few other changes which were related to AutoField:
>> ForeignKey needs to find out the actu
On 8 June 2010 18:30, Gonzalo Saavedra wrote:
> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> adding a new tag for this.
>
> I also use {% with %}{% include %} a lot in templates but we should
> follow with/blocktrans syntax for consistency:
>
> {% include "part.html" with ob
I'd suggest to change both include and with/blocktrans syntax into
more programmer-friendly style:
{% include "part.html" title=obj.title|capfirst main_class="large" %}
This is both more dense, and from quick grasp you can see where are
the delimiters ("as" is not so good for this).
Also I think
Also +1 from me for extending the include tag instead of having a new one.
Bye default it should keep its behaviour and use the current context
for the included template. Marco's use of a new, clean context
(demonstrated with the snippet below) is also possible to support.
{% if label %}
This abstract base class likely is a bit less performant than having
in-db support for cascades in pgsql... though it should give you the
behavior you are seeking.
It should set to default, or null if allowed.
Enjoy.
-k
class ClearOnDelete(models.Model):
def delete(self):
related_obje
On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald
wrote:
> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor wrote:
>> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald
>> wrote:
>>> Why did you revert the AutoField patch? BTW, in the Django-nonrel
>>> patch you'll find a few other changes which w
On 8 June 2010 13:09, Jeremy Dunck wrote:
> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson wrote:
>> I've now had to learn this the hard way by having real live data
>> deleted from my database on two production projects and it pisses me
>> off big time every time.
>>
>> I can accept that NOT nu
On Tue, Jun 8, 2010 at 8:55 PM, Alex Gaynor wrote:
> On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald
> wrote:
>> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor wrote:
>>> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald
>>> wrote:
Why did you revert the AutoField patch? BTW, in the Dja
Hi,
it's long time ago, that I have contributed code to django. But at the
moment I work at the admin pages of a django-driven web site. And
because of even though django's admin is powerful, it still needs a lot
of improvement. So I have started to write a few patches. I have
created a ticket wit
Hey Sebastian --
Thanks for the reminder; I'll take a look when I get a moment.
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-develop...@googlegroups.com.
To unsubscribe from this group,
Hey Sebastian --
Okay, turned out I had a moment now. I've reviewed your tickets. See
each one for particular comments, but in general they look good.
However, they're all missing documentation and tests, which need to be
present before they can be checked in. If one of these tickets line up
with
On 25 May 2010 07:50, Simon Meers wrote:
>
> I've uploaded some screenshots [1] of the new patch for #13163 [2] and
> #13165 [3] in action, to allow people to see the affect without
> necessarily applying the changes.
>
> These enhancements have *vastly* improved the navigability of the
> admin in
I have a pending admin patch too: http://code.djangoproject.com/ticket/11651
(With tests and docs, though probably needs some better function
names.)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
22 matches
Mail list logo
