I don't have any strong objections at this point, just wanted to think it
through and offer possible alternatives. If there's no further input, I'll
finish adding tests and docs for the TEMPLATES 'POST_APP_DIRS' option
tomorrow, after which I think the widget rendering patch will be ready for
f
Hi Tim,
On 12/14/2016 12:50 PM, Tim Graham wrote:
> My thinking is that there should typically be only one directory in each
> project that overrides built-in templates, otherwise if multiple apps
> provide overrides, they'll stomp on each other when using the
> app_directories loader.Are your pro
My thinking is that there should typically be only one directory in each
project that overrides built-in templates, otherwise if multiple apps
provide overrides, they'll stomp on each other when using the
app_directories loader. Are your projects usually set up that way? Using
the app_directori
Hello,
Not sure this is the right place to post this, if not, could somebody point
me to the right place?
I recently had the need to use GeoDjango to define a model that uses a
RasterField to store a GeoTIFF
raster.
https://docs.djangoproject.com/en/1.10/ref/contrib/gis/model-api/#rasterfield
On 12/14/2016 11:08 AM, Carl Meyer wrote:
> As for whether a hypothetical third-party app that wants to override
> form widgets should do it by just providing the template overrides and
> clearly documenting that, or should do it by providing a custom form
> renderer, that's a separate question. I
On 12/14/2016 10:27 AM, Tim Graham wrote:
> I'm not sure if having the default renders insert the built-in form
> templates directory after the app dirs (as opposed to before, as usual
> with 'DIRS') is the best approach. On the PR, we discussed adding a new
> TEMPLATES 'POST_APP_DIRS' option to ac
I'm not sure if having the default renders insert the built-in form
templates directory after the app dirs (as opposed to before, as usual with
'DIRS') is the best approach. On the PR, we discussed adding a new
TEMPLATES 'POST_APP_DIRS' option to accomplish this but it might be
unneeded complex
Hello,
thanks for the hints
Il 13/12/2016 19:51, Tim Graham ha scritto:
There are a few open tickets that may be related:
https://code.djangoproject.com/ticket/23521 - removal of concrete Model from
bases doesn't remove it from ModelState bases
Yeah, this looks like it. This also is an inter
