Thank you Sir for reply.
*
--
Cheers,
Mayur*
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to
On 6 mars 2013, at 23:21, Aymeric Augustin
wrote:
> using a WSGI middleware. It's two lines of code:
>
> from django.core.wsgi import get_wsgi_application
> application = get_wsgi_application()
>
> for db in ('default', 'other'):
> application = atomic(using=db)(application)
>
> I'm lean
My work on transaction management is now ready for review:
https://github.com/django/django/pull/873
To sum up, the main improvements over the current implementation are:
1) A better API for transactions
- Simple: just one function covers most of the use cases
- Correct: it actua
Hi folks --
This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.
My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and ha
On 03/07/2013 09:48 AM, Jacob Kaplan-Moss wrote:
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus
A good idea, +1.
четверг, 7 марта 2013 г., 22:48:11 UTC+6 пользователь Jacob Kaplan-Moss
написал:
>
> Hi folks --
>
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care mu
On 7 mars 2013, at 17:48, Jacob Kaplan-Moss wrote:
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
+1
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then D
On Mon, Feb 25, 2013 at 4:48 PM, Florian Apolloner
wrote:
> So all in all I think we could enable travis,
I agree, +1 from me.
> but I have two questions:
> * How much bash magic do we want in the .travis.yml file? One option would
> be to use a separate repo like I did in my initial work:
> ht
Seems to me that if database backends were separate from Django then the
postgres backend would get a long way ahead of the others as much as the
other backends would get behind - it's bound to attract the most work and
be adding custom fields like hstore, arrays, json... I think this would be
On Mar 7, 2013, at 11:48 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care much about how comments
> work but just want some
I think i can maintain comments if you want the time you need.
I only use few zinnia blogs, then, is not really important to me, but I
suppose it is important for many others developers.
Best Regards
On Thu, Mar 7, 2013 at 11:00 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
Jumpin' on the +1 train.
Choo, choo!
Alex
On Thu, Mar 7, 2013 at 9:04 AM, Donald Stufft wrote:
> On Mar 7, 2013, at 11:48 AM, Jacob Kaplan-Moss wrote:
>
> > Hi folks --
> >
> > This one's simple: I'd like to deprecate `django.contrib.comments`,
> > scheduling it to be removed in a couple of r
+1 from me too - I've only tried using django.contrib.comments once, and it
ended up not being what I needed anyway, so I had to write my own comments
module (Disqus was out of the question)
On Thu, Mar 7, 2013 at 5:11 PM, Carlos Aguilar wrote:
> I think i can maintain comments if you want the t
On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn wrote:
> I don't know why Oracle is included and MSSQL is not [...]
It's essentially because a group of people made a concerted effort to
get the Oracle backend up to snuff (around the 1.0 timeline, I think?)
and then committed to maintaining it. Lately
I think it can't just disappear. Even if you can't find a maintainer, core
should put at least a little effort to make sure that an API compatible
third-party application exists that is compatible at least through version
1.8 when "import django.contrib.comments" stops working (basically, do the
wo
It's worth mentioning that Django appears in the Python Tools for Visual
Studio (it's one of the default project templates)[1]. There's recent
introductory material on deploying Django applications to Windows Azure[2]
and Windows Server 2008[3], though it seems the older material at least
explicitl
On Wednesday 06 March 2013, Aymeric Augustin wrote:
>
> So part 3 of the plan is to replace TransactionMiddleware by something
> based on transaction.atomic that actually works. For lack of a better
> idea, I'm considering deprecating the middleware and replacing it with a
> setting. This doesn't
On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown wrote:
> I've only tried using django.contrib.comments once, and it ended up not
> being what I needed anyway, so I had to write my own comments module (Disqus
> was out of the question)
i had exactly the same experience.
--
Javier
--
You r
Hello,
There was some discussion on the current limitations of the ModelForm
API in the past couple of days on IRC, I'd like to make a proposal to
address some of them.
I wrote django-floppyforms, a library that lets you render forms using
templates instead of python code. It behaves exactly like
+1
This logic would be better in `ModelForm`.
--
Loic
On Mar 8, 2013, at 2:42 AM, Bruno Renié wrote:
> My proposal is to move that field customization API from the
> ModelAdmin class back to ModelForm:
--
You received this message because you are subscribed to the Google Groups
"Django dev
Other possible option is for ideas:
http://django-crispy-forms.readthedocs.org/en/latest/index.html
;)
2013/3/7 Loic Bistuer
> +1
>
> This logic would be better in `ModelForm`.
>
> --
> Loic
>
> On Mar 8, 2013, at 2:42 AM, Bruno Renié wrote:
>
> My proposal is to move that field customization
Hi Bruno,
On 03/07/2013 12:42 PM, Bruno Renié wrote:
> * Move formfield_for_* to ModelForm and document them as public APIs
> * Deprecate `formfield_callback`
> * Write an AdminModelForm class that implements all the admin form
> fields and widgets customization
> * Modify ModelAdmin to make use o
Hi
I'm currently working on a project where I don't use db.* and I met a
problem during testing. As django.test.testcases.TestCase [1] inherits from
TransactionTestCase, it complains about "ImproperlyConfigured:
settings.DATABASES". A solution is to fall back to SimpleTestCase (which
Transacti
On 03/07/2013 01:32 PM, zalew wrote:
> I'm currently working on a project where I don't use db.* and I met a
> problem during testing. As django.test.testcases.TestCase [1] inherits
> from TransactionTestCase, it complains about "ImproperlyConfigured:
> settings.DATABASES". A solution is to fall ba
Hi all,
It seems to me we are mixing a few different discussions here:
1. Should Django core have as few database backends as possible?
1a. If yes, which ones should stay in Django core?
2. What should we do, if anything, with the current situation where
it seems difficult to guarantee the qu
On 7 mars 2013, at 17:37, Aymeric Augustin
wrote:
> My work on transaction management is now ready for review:
> https://github.com/django/django/pull/873
It also fixes at least ten tickets. Here's a short explanation for those I
found.
#2227: `atomic` supports nesting.
#6623: `commit_manual
On Thu, Mar 7, 2013 at 5:32 PM, zalew wrote:
> fall back to SimpleTestCase (which
> TransactionTestCase inherits from), but this class doesn't contain useful
> test helpers, which aren't in any way related to db handling:
>
> * assertRedirects
> * assert(Not)Contains
> * assertFormError
> * assert
On Fri, Mar 8, 2013 at 12:48 AM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care much about how comments
> work but just want som
Here's something I've been thinking about:
As a rule, assuming that backends are not bug-riddled and do not have
needlessly shoddy performance, nearly all of the value of an ORM is in the
set of frontend features it exposes to application developers. Given a
certain frontend API, then the only val
> +1 to you proposal. Please open a ticket.
>
done https://code.djangoproject.com/ticket/20004
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-d
On Thursday, March 7, 2013 1:05:53 PM UTC-5, Alex Ogier wrote:
>
> I think it can't just disappear. Even if you can't find a maintainer, core
> should put at least a little effort to make sure that an API compatible
> third-party application exists that is compatible at least through version
>
It's not like /dev/null'ing it erases it from the annals of history. I
don't see what the point of creating an un-maintained repo is, if someone
decides they want to maintain it at some later point it's pretty trivial to
resurrect from VCS history.
Alex
On Thu, Mar 7, 2013 at 4:29 PM, Michael Ma
On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee
wrote:
> However, I'd argue against using /dev/null as a disposal mechanism. I don't
> think the code should ever completely disappear. If someone offers to take
> over, that's great; but just because nobody volunteers to maintain the
> project,
On Fri, Mar 8, 2013 at 7:57 AM, Alex Ogier wrote:
> Here's something I've been thinking about:
>
> As a rule, assuming that backends are not bug-riddled and do not have
> needlessly shoddy performance, nearly all of the value of an ORM is in the
> set of frontend features it exposes to applicatio
On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee wrote:
> I completely agree with Jacob's analysis of the status quo, and I agree
> largely with his position on having MSSQL in the core.
>
> I'd have no problem seeing MSSQL in the core - it's at least as high
> profile as Oracle, and although
+1
Sent from my Windows Phone
From: Jacob Kaplan-Moss
Sent: 3/7/2013 5:48 PM
To: django-developers
Subject: Proposal: deprecate and remove django.contrib.comments
Hi folks --
This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.
Huh?? I am running sqlite with GIS on my laptop right now. It wasn't THAT
hard to install. Yes, the documentation could use some cleanup, but it got
me through the tutorial okay and gives me a platform to learn GIS on.
I really support the idea of sqlite and postgres in the core and moving
As for me, wearing my FOSS-only developper hat, I'd suggest we only include
backends in core for products having an OSI-approved license. And yes, the
Oracle backend is already problematic at this regard. That would mean I'm
-0 to -1 for including any other db backend (or any other component) b
38 matches
Mail list logo
