Oops, terribly sorry folks. I'll repost to the django-users group.
--
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 unsubscribe from this group, send email to
djan
On Tue, Jun 8, 2010 at 10:21 AM, ingraveswetrust
wrote:
> Hello fellow Django enthusiasts! I'm a very new Django user, and have
> been experimenting with Django 1.2 for the last few weeks. Thus far,
> I love it! I love that it has thus far been so simple for me to
> learn, that the documentatio
Hello fellow Django enthusiasts! I'm a very new Django user, and have
been experimenting with Django 1.2 for the last few weeks. Thus far,
I love it! I love that it has thus far been so simple for me to
learn, that the documentation is actually readable and simply written,
and that the set up wa
Hey all,
If you saw my email last week you know that my goal for the bulk of
the GSOC work was going to be refactoring the Query class to be less
SQL/relational db specific. After spending much of last week taking a
few different approach at this it's become clear to me that that
approach would r
Extending the include tag seems like a fantastic idea! I end up
writing the {% with %}{% include %} combo all the time for my reusable
template snippets.
However, I feel like selectively clearing the context inside a
template tag is asking for trouble and/or confusion. It also sounds
like it goes
For the record, the "from settings_default..." method is exactly how
my team's largest projects are deployed. It works just fine for us!
Even more fun (though bordering on too tricky) is converting
INSTALLED_APPS to a set instead of a list so you can add *or* subtract
items.
This whole argument h
I'd prefer extending the {% include %} tag actually, but didn't of
that in the first place.
The clean context implementation was to make sure we don't pass
variables we don't want to. One of the use-cases is including form
field "templates", so I have code like:
{% if label %}
On Mon, Jun 7, 2010 at 5:38 PM, Chris wrote:
> On Jun 7, 10:45 am, Alex Gaynor wrote:
>> On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
>> >> try:
>> >> from settings_local import *
>> >> except:
>> >> # It's ok to not have any local settings.
>> >> pass
>>
>> > This pattern is used by almos
2010/6/7 Łukasz Rekucki :
>> {% include "some/template.html" with foo=bar baz=spam %}
> Personally, I would expect this to extend the current context with
> "foo" and "bar", render the include and restore foo, bar to old values
> (if any). Using a clean context instead is a bit non-obvious to me
On Jun 7, 10:45 am, Alex Gaynor wrote:
> On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
> >> try:
> >> from settings_local import *
> >> except:
> >> # It's ok to not have any local settings.
> >> pass
>
> > This pattern is used by almost everybody it seems. Is there any reason
> > why this p
On 7 June 2010 18:13, Jacob Kaplan-Moss wrote:
> On Mon, Jun 7, 2010 at 5:03 AM, Marco Louro wrote:
>
>> I'd like to propose adding a tag that includes a template with clean
>> context, but can accept parameters that will be added to that
>> context.
>
> Is there a reason to do this as a separate
On Mon, Jun 7, 2010 at 5:03 AM, Marco Louro wrote:
> I'd like to propose adding a tag that includes a template with clean
> context, but can accept parameters that will be added to that
> context.
Is there a reason to do this as a separate tag? Why not just::
{% include "some/template.html"
I added the test and made a patch (two actually). Thanks a lot for your help :-)
--
Filip Gruszczyński
--
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 unsubscribe
On Mon, Jun 7, 2010 at 1:15 AM, Chris wrote:
>> try:
>> from settings_local import *
>> except:
>> # It's ok to not have any local settings.
>> pass
>
> This pattern is used by almost everybody it seems. Is there any reason
> why this pattern hasn't been adopted by "django-admin.py startproj
2010/6/7 Filip Gruszczyński :
>> The positive test cases (i.e., this model *doesn't* raise an error)
>> aren't explicitly tested, beyond the fact that all the other models in
>> the test suite need to validate before the test suite will run.
>
> So I can put new test together with some other orderi
> The positive test cases (i.e., this model *doesn't* raise an error)
> aren't explicitly tested, beyond the fact that all the other models in
> the test suite need to validate before the test suite will run.
So I can put new test together with some other ordering tests and this
should do the tric
2010/6/7 Filip Gruszczyński :
> There is a small issue concerning validate command and ordering model
> by pk. I would like to write a test for this (and a patch too), but I
> have no idea where to put those tests and how exactly use it.
> get_validation_errors from core.management.validation is us
There is a small issue concerning validate command and ordering model
by pk. I would like to write a test for this (and a patch too), but I
have no idea where to put those tests and how exactly use it.
get_validation_errors from core.management.validation is used on an
app and writes the result to
On Mon, Jun 7, 2010 at 12:28 PM, burc...@gmail.com wrote:
> You have special person for configuring a project.
I wish; just different hats for different tasks.
> You will still be happy.
Only because this sort of auto configuration will not be going into
django, that much has been made abundant
On Mon, Jun 7, 2010 at 4:39 PM, Tom Evans wrote:
> Are you proposing to determine the host name and then dynamically
> import settings from that named configuration file? What a kludge -
> that would require having every configuration file for all your sites
> checked out in the same place.
I'm no
Hi Marco,
Please also get a look at http://github.com/buriy/django-containers
Which implements exactly the same, but allows larger chunks:
{% part left%}{% trans "arbitrary contents" %}{% endpart %}.
On Mon, Jun 7, 2010 at 5:03 PM, Marco Louro wrote:
> Hi all,
>
> I'd like to propose adding a ta
Hi all,
I'd like to propose adding a tag that includes a template with clean
context, but can accept parameters that will be added to that
context.
The use-cases are plenty, but I've been using it mostly with forms, as
it helps to keep the template code DRY and very customizable. We could
use the
On Sat, Jun 5, 2010 at 11:22 AM, burc...@gmail.com wrote:
> These are exactly my hate patterns.
> The goal of django-configurator was to get rid of them in the projects I have.
So? Problem solved, you can run your projects in precisely the manner
you choose, using your app.
Why then do you
23 matches
Mail list logo
