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
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
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
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
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
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 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 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
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
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
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
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 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
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
>
> 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,
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
>
> 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,
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
>
> 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
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
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
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
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
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
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
>
> 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
>
> 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
> 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
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
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
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
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
>
> 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
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
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
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
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
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
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
+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 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
>
> 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
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
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
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
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
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
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
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
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
+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
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#
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
>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
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
55 matches
Mail list logo
