Just for the record, there's also
https://github.com/pydanny/django-admin2, another project that attempts
to create a more modular and extensible admin.
Danilo
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group
Could Django provides a way to render forms in HTML5 syntax? It now render
forms in XHTML syntax as
Or could it in the settings provides an option as USE_HTML5 for applying
that?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubs
I'm doing some refactoring of a Django app and I want to make sure that I
don't introduce any really poorly performing pages as a result of poor
queries.
I want to write a test that tries every registered URL and makes sure that
none of them has an excessive number of queries.
AssertNumQueries
That is not just XHTML but perfectly valid HTML5.
Cheers,
Florian
On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote:
>
> Could Django provides a way to render forms in HTML5 syntax? It now render
> forms in XHTML syntax as
>
> Or could it in the settings provides an option as USE_HTML5
AssertNumQueries is often a problem for 3rd party backends.
AssertMaxQueries would become the same and likely result in poorly written
tests because of the inherent slop factor in the arbitrarily chosen max
value.
I'm not opposed to Django adding this. I'm opposed to Django using it in
its own tes
I like the idea -- if nothing else, it would provide an easy way to have a
test suite discover N+1 problems, especially in templates.
Not sure about the feasibility, though; would you be willing to work up a
rough implementation of it?
--
You received this message because you are subscribed to t
On Sunday 17 August 2014 17:36:12 Michael Manfre wrote:
> AssertNumQueries is often a problem for 3rd party backends.
> AssertMaxQueries would become the same and likely result in poorly written
> tests because of the inherent slop factor in the arbitrarily chosen max
> value.
>
I agree with the
I am not so convinced, what would you put in as the upper limit? While
preventing n+1, it still requires you to know what n in this testcase is
and changing n can lead to funny errors. Currently we are documenting
(hopefully) how those query counts come together, so it's clear what's
happening
But I don't sure that when it's using XHTML and HTML5 syntax together and
it should use one syntax for rending views.
It might cause issues when templates are using HTML5 syntax but forms are
using XHTML syntax?
On Sunday, August 17, 2014 10:28:43 PM UTC+8, Florian Apolloner wrote:
>
> That is n
Browsers are extremely good at parsing whatever gets thrown at them. They
accept a mix of self-closing and unclosed tags easily.
If you can describe a use case where self-closing tags create an actual,
reproducible problem, then we'll have a discussion.
If you were just asking for the purity of
I use this method on my own test subclasses, and I find it useful as a
tripwire: a cause for review and consideration, more than a hard error. Did
the number of queries go up on this change? Is that reasonable or a
mistake? Have we blown the perf budget so we should refactor? Or maybe the
number sh
On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote:
>
> It might cause issues when templates are using HTML5 syntax but forms are
> using XHTML syntax?
>
The forms are not using XHTML syntax per se, they are valid HTML5 and valid
XHTML!
--
You received this message because you are sub
+1 - useful for user code that guards against accidental poor ORM usage.
On Monday, 18 August 2014 05:47:15 UTC+10, jdunck wrote:
>
> I use this method on my own test subclasses, and I find it useful as a
> tripwire: a cause for review and consideration, more than a hard error. Did
> the number
You can use Django Crispyforms
El 17/08/2014 22:43, "Florian Apolloner" escribió:
>
>
> On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote:
>>
>> It might cause issues when templates are using HTML5 syntax but forms are
>> using XHTML syntax?
>>
>
> The forms are not using XHTML syntax per
FYI - I've just made this change (and restored the homepage content again,
which seemed to go missing...)
Yours,
Russ Magee %-)
On Sun, Aug 17, 2014 at 8:55 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> Hi Colin,
>
> Good suggestion - and kinda obvious now you mention it! I'll mak
Thanks for the mention, but I haven't had time to work or maintain that for
months. I'm not sure how it works with the upcoming Django 1.7. Also, for
the sake of simplicity, the default skin for it is bootstrap 3. Any CSS in
there is per skin, and probably doesn't belong in this discussion.
On
Hi Anssi,
On Sun, Aug 17, 2014 at 3:06 AM, Anssi Kääriäinen
wrote:
> On Saturday, August 16, 2014 4:38:30 AM UTC+3, Russell Keith-Magee wrote:
>>
>> b) "Relating" data fields - This means ForeignKey. Fields that manifest
>> as a single column, but represent a relation to another model.
>>
>
> Th
Hi Shai,
On Sun, Aug 17, 2014 at 3:44 AM, Shai Berger wrote:
> Hi,
>
> It seems to me that the taxonomy doesn't handle well FileField and
> ImageField.
> It could be bundled in with ForeignKey (as the data it really represents is
> only pointed at by the related column data), but not with the cu
On Sunday, August 17, 2014 8:39:17 PM UTC+6, James Bennett wrote:
>
> Not sure about the feasibility, though; would you be willing to work up a
> rough implementation of it?
>
Implementation of the assertion is straightforward, because it can be a
direct copy of AssertNumQueries with:
self.tes
19 matches
Mail list logo
