Carl,
The default renderer is backwards-compatible with no settings changes,
> and does not require Jinja2, but it still allows overrides/additions of
> widget templates. It's also standalone-compatible, in that it is
> self-contained and has no dependency on TEMPLATES config.
I like this id
>From my experience the silent failure is more confusing than helpful. I
like Jinja's approach here that enables missing templates to be explicitly
silenced when desired, i.e.:
{% include "sidebar.html" ignore missing %}
Preston
--
You received this message because you are subscribed to the G
Yep, that looks wrong. Looks like it was added in this commit:
https://github.com/django/django/commit/f33db5a09acfc3df3085235a5712c46094eb9a0d
The test case could be improved also by checking the appropriate key is set.
Preston
--
You received this message because you are subscribed to the Go
Hey Curtis,
I think you're asking how this patch will help with form and field layouts?
If so, not that much. It only addresses moving the widget HTML that
currently is hardcoded in Python into templates.
For example, compare:
https://github.com/django/django/blob/master/django/forms/widgets.py#
+1. I like the simpler fallback solution Carl has suggested also.
Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
When I created my initial branch for this, it was easy enough to auto
reload a file once it changed, but it was difficult to deal with template
directory precedence. For instance, if `admin/base.html` was cached, but a
custom `admin/base.html` was added in a loader or directory with higher
prec
>
> Yes I know that you can access the Field instance but it wouldn't be
> possible to do {{ field.field.city }} since a Field is not supposed to
> have any data stored with it.
>
This makes sense to me. Feel free to make a ticket and attach your PR once
it's ready for review.
Preston
--
Y
Hi Moritz,
Is the purpose of this patch to have a more convenient form of this:
{% for choice in form.foo.field.choices %}
{{ choice.0 }} {{ choice.1 }}
{% endfor %}
I'm not necessarily against the idea, but your patch seems to encourage
looping over the field choices rather than the widget c
+1. Eggs have reached the point of obsolescence.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubsc
Hi Carl,
Thanks for the feedback. I agree with your suggestions. I didn't think about
running a check for a combination of INSTALLED_APPS and a loader with
APP_DIRS. That would be sufficient for customizing loading.
I'll update and convert this to a PR.
Preston
--
You received this message bec
Hi all,
I've been working through solutions for #15667 -- template based widget
rendering. This is a problem that was close to a solution at one time, but
stalled out due to performance concerns and difficulties with defining a
workable API to create configurable template loaders.
Now that Jinja2
Yep, I think you're right now. Given existing solutions there's not warrant
enough to add another built-in validation hook.
Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this
Since I think this can be a useful feature, I'll explain why.
One use case is for validating address forms. We deal with a lot of
them with varying levels of validation based on country, state, zip
code, etc. Sometimes, multiple sets of address fields appear on the
same form. We can't simply reuse
There are times when I've definitely wanted this feature. Particularly,
when multiple fields on a form have this type of constraint. Putting all
the logic in the clean method gets convoluted.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Con
was worth sharing my
> findings since - particularly in the context of Preston's suggestion that
> we might find a bottleneck - I don't think there is one particular
> bottleneck.
>
> Our "solution" for now has been to speed up the processors in our servers
&g
>
> After a while I believe layers and layers of caution have accrued, and
> nobody is sure any more where these have overlapped excessively.
>
Do you have examples of which layers these are?
Escaping seems to happen in Variable, VariableNode, FilterExpression, and
render_value_in_context. I d
Hi Oleksii,
I found that cProfile isn't that helpful when rendering templates. There
are a lot
of function calls and the output is too verbose to really reveal where
Django
spends it's time.
Also, keep in mind that rendering is only one step of the template cycle,
and
usually only a small part
My branch is updated. This now combines the origin classes into one. It also
includes a simpler cache algorithm than before. This same algorithm can be
used if we implement an internal cache to the engine, which is now a small
addition to this patch.
I'd like to see origin.reload go away but it's
Hey Curtis,
I was working to remove origin.reload and ended up with a fork that
combines the debug implementation:
https://github.com/django/django/pull/4254
On a complex template with debug off I'm measuring about a 5% increase in
template compile time compared to master. Turning debug on add
A small update:
I have a local branch working again, but nothing ready to review.
I have decided the origin.status and origin.tried apis I mentioned above
aren't
going to work. For templates to be safely cacheable in a multi-threaded
environment, they basically need to be treated as immutable. A
> In that case, would it be possible to do the caching improvements before
> the main
> refactoring? I'm trying to keep patches at a reviewable size :-)
>
> --
> Aymeric.
>
Maybe. The existing loaders don't provide a nice way to add
Origin.uptodate. It would
require an informal hack that only
>
> Yes, I do.
>
> This is an independent follow-up to the big refactoring we’re talking
> about, isn’t it?
Cool.
It depends. The cached loader is what I'm least happy with in my
refactoring. This
internal cache idea I think is simpler, more performant, and easier to
understand.
Adding it
>
> Thanks for your continued work on this and sorry for my slow answers.
>
No worries. I've been taking the time to get a better grasp of Django
templates as a whole.
> > Does that makes sense, or should I look for a way to incorporate that
> > into LoaderOrigin?
>
> Looking at the implem
After looking at this, there's nothing special about blocks compared to any
other node. They could just as well be evaluated at render time.
Here's a branch that implements this change:
https://github.com/prestontimmons/django/compare/conditional-blocks?expand=1
Before returning blocks into blo
Here are some benchmarks I added here:
https://github.com/prestontimmons/templatebench
This is the cumulative time to do 1000 iterations:
Basic.do_init: 0.1423451900
BasicDebug.do_init: 0.1941769123
35% increase in parsing time
Basic.do_parse_complex: 1.2230978012
BasicDebug.do_parse_complex: 1
Hi Aymeric,
I'm thinking of proposing an alternative to the cached loader. This new
approach makes Django faster in general.
To start, I put together some benchmarks here:
https://github.com/prestontimmons/templatebench
The goal was to identify where Django spends it's time. Is it the loaders
My pull request is updated with a simplified cache loader and docs. I also
found
some nicer solutions to some of the hackier things, like making origin
available
to the ExtendsNode.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
The trickiest tests to move will be the gis tests.
When gis is enabled, django/contrib/gis/tests is added to the discovery
path. This doesn't affect which tests are discovered per se--all gis tests
are discovered anyway by discovery on the parent app
django.contrib.gis--but it causes the later
I think the "need" is mainly conceptual--whether tests are more
appropriately grouped with their app or with the other tests. With the
discover runner it's uncommon that contrib tests are included in any local
test runs.
I do prefer moving all tests into the tests directory. The logic to get
t
>
> I suspect it has to do with {% if %} being interpreted at runtime while
> {% block %} is interpreted at compile time.
>
> I never investigated this fully. If someone does, I’m interested :-)
>
> --
> Aymeric.
>
I took a look at how this works. The issue comes from a naive approach to
ho
Hi Aymeric,
It took me awhile, but I haz an update:
https://github.com/django/django/pull/3475
Loader cleanup
This addresses the code duplication between get_internal and
load_template_sources. I also made the app directories loader inherit
from the filesystem loader, since the only real differ
>
> Perhaps we’ll bikeshed names at some point but let’s leave the “naming
> things” problem aside for now.
> “name” must be optional for loaders that don’t load templates from
> files.
> “loadname” must be optional too for templates instantiated from
> strings.
> Here option
Hi Aymeric,
I got a chance to update my patch with the use of origins. The good news is
that it's simpler than the old implementation. I have a few api questions
below. The updated branch is here for now:
https://github.com/prestontimmons/django/compare/ticket-15053-origin?expand=1
As a quick re
>
> The debugging information is two dimensional data: for each level of
> template extending, for each template loader, you have one entry —
> entries are 4-tuples in your current proposal.
Yes, this is correct. Although there may not be an entry for each loader on
each level of ext
Hi Aymeric,
Thanks for the feedback!
>
Even if it isn’t consistently implemented, the loader API is documented:
>
> https://docs.djangoproject.com/en/1.7/ref/templates/api/#using-an-alternative-template-language
> To sum up:
> load_template_source(template_name) —> (template_str
Hi Unai. Yes, your previous work was helpful for me in developing this
solution. Some of Aymeric's recent refactorings have simplified things
since you last worked on it as well.
Hi Riccardo. Thanks for the suggestion. I don't mind changing the name of
get_internal if others agree. That's an ea
At work we use a --no-migrate flag on our test runner. It's helpful when 1)
we're developing a new app but the models aren't nailed down yet, and 2) it
speeds up the test suite time significantly.
The --keepdb option is sufficient for scenario 2, but doesn't do much for
scenario 1. Admittedly t
Hi all,
I've been working on #15053, which enables Django template loaders to extend
templates of the same name recursively. The most common use-case for this is
extending the admin templates without needing to copy the application
templates
into a project.
To illustrate the new algorithm, here
I agree about the select_template() change as well.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsu
Aymeric,
Great work on this. I have a few more questions:
First, if multiple engines are configured, how do you see the error being
displayed if a template isn't found in any of them? Currently, this
originates from the template loaders. For instance, the filesystem loader
raises a TemplateDoe
Hi Aymeric,
With the new template update, do you foresee
django.utils.setup_test_template_loader and
django.utils.restore_template_loaders still working?
Those aren't officially public api's, but they're useful nonetheless.
Perhaps the way to do it in the future would be with override_settings
Hi Shai,
The discover runner does discovery based on pattern.
So, if your tests are named, test_*.py, they would by be discovered by
default. Test discovery is recursive, under the root, so it doesn't
matter if you have tests in a tests directory.
The __init__.py imports would be redundant, and
Hi all,
There are some important design decisions to be made if we include
unittest2 discovery into Django.
This message documents a proposed API, the pros and cons, and
decisions that need to be made.
https://code.djangoproject.com/ticket/17365
-- Limitation of current test setup: --
* Tests
Hi,
I have a question for somebody more experienced with the Django
template system internals.
The template loader load_template method is documented as such:
"The load_template() method of the Loader class retrieves the template
string by calling load_template_source(), instantiates a Template
This looks excellent so far.
Do {% formfield %} and {% formrow %} accept context like {% form %}
does?
Is there a way with {% formfield %} or {% formrow %} to set custom
attributes like placeholder, autocorrect, etc.? I find this common
requirement when optimizing forms for mobile devices.
Thank
This looks interesting so far.
How does setting the form layout affect rendering individual fields in
a form?
Is the output of {% renderform my_form "first_name" %} equivalent to
{{ form.first_name }}, or is it more like the output of "as_p" or
"as_table"? Which templates are involved in a form l
Hi,
Could one of the core devs take a look over #10899 and give some
guidance on what the best step to take next is? Thanks.
Preston
--
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...@goo
I'm a fan of this proposal. I find that most of the tags I build
return a variable to the context rather than just rendering a string.
And while a few of the tags I have built require more complexity than
the decorator approach could handle, the majority of them would be
trivial to make if this wer
Hey Russ,
I think this is a great proposal so far!
Is there a way with the proposed solution for the template designer to
add custom attributes to a form field? If so, do you envision that
happening in the chrome layer?
Here's a use case:
The designer wants to render an email input field. They
Congratulations! Thanks for all your hard work on this. There's not
another framework I'd rather use.
Preston
--
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 unsub
Hi Rob,
On Feb 19, 11:58 am, Rob Hudson wrote:
> On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
> 1) Do we put jQuery in base.html and have Django's widgets and plugins
> assume it will be there?
>
> * Benefits: Javascript admin customizations are simpler and can use
> the jQuery already on
of mine as well.
>
> > > On Apr 3, 12:33 pm, Preston Timmons wrote:
> > >> I would be interested in coming as well.
>
> > I assume you guys are OK with either weekend, then?
>
> > Brett
--~--~-~--~~~---~--~~
You received this
I would be interested in coming as well.
On Apr 3, 9:50 am, Jeremy Dunck wrote:
> Gary, Justin?
>
> On Fri, Apr 3, 2009 at 9:47 AM, Alex Robbins
>
>
>
> wrote:
>
> > I live in the Dallas area and would be interested in coming, whenever
> > it happens.
>
> > On Apr 2, 12:45 pm, Jeremy Dunck w
normal inline options.
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#inlinemodeladmin-options
I thought I would mention that because it seems like a feature is
already documented as working.
Preston
On Mar 19, 8:54 pm, Brian Rosner wrote:
> On Mar 19, 2009, at 5:47 PM, Preston Timm
Ticket #9122 Inline admin on generic relations ignores exclude and
max_num
http://code.djangoproject.com/ticket/9122
Might somebody be able to review the patch and tests for this ticket
to see if they are acceptable? I am hoping it can get in as a bug fix
for 1.1. If something is lacking here I w
55 matches
Mail list logo