Re: Is it possible to use Django with an API as its back-end?
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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is it possible to use Django with an API as its back-end?
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 documentation is actually readable and simply written, > and that the set up was sooo fast and painless. > > As an interesting stroke of good fortune, it turns out that my > employer is currently evaluating new technology stacks as we plan the > complete rewrite of our current site. The site does ~16m uniques a > month, and we are gravitating toward an API-based back-end. In my > part of this evaluation, I'm having some trouble tracking down > information about the following two concerns: > > 1) Is it possible to run Django on an API, rather than replicating > data as seen here: > http://www.webmonkey.com/2010/02/Integrate_Web_APIs_into_Your_Django_Site/? > 2) What kind of performance should we expect (Django 1.2/Apache/MySQL > versus something like Zend Framework/Apache/MySQL)? Django-developers is for discussing the development of Django itself. If you have general usage questions, they should be directed to django-users. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Is it possible to use Django with an API as its back-end?
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 was sooo fast and painless. As an interesting stroke of good fortune, it turns out that my employer is currently evaluating new technology stacks as we plan the complete rewrite of our current site. The site does ~16m uniques a month, and we are gravitating toward an API-based back-end. In my part of this evaluation, I'm having some trouble tracking down information about the following two concerns: 1) Is it possible to run Django on an API, rather than replicating data as seen here: http://www.webmonkey.com/2010/02/Integrate_Web_APIs_into_Your_Django_Site/? 2) What kind of performance should we expect (Django 1.2/Apache/MySQL versus something like Zend Framework/Apache/MySQL)? Any information, or nudges in the the right directions would be much appreciated! -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
[GSOC] Query Refactor Status Update
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 result in very high up time costs. After speaking with Russell I've changed up the project plan somewhat. I'm going to start with actually creating the backend (MongoDB) and deal with most of the difficulties with things like insertion, updates, and everything mostly unrelated to the Query class. And after that's more or less done I'll move on to the complex refactorings. As you can see the fruits of these efforts have already begun to land in my branch, and I suspect that the multidb refactorings of last year have left us in a better state than I appreciated: while the concepts and data structures used in the Query class are relational/SQL biased (joins, where vs. having, etc.), the data itself is entirely backend neutral. This means that getting a "stupid" MongoDB backend that can handle trivial filters should be relatively easy, and then it can be evolved to work with the better datastructures I'll be refactoring Queyr to eventually use. If you have any questions, just ask. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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 against Django's "templates require no knowledge of
programming" principle. While I can see how you might run into context
name collisions in a *very* large or complicated project, the right
solution there seems like it ought to be to clean up your context and/
or templates outside of the template itself... Even in projects with
dozens of installed apps (both my own and third-party ones mixed
together) I've never had that problem where two minutes of tweaking
couldn't fix it for good.
I'm certainly not saying you don't have a use case for it, or that it
wouldn't be extremely helpful to you. Just that having a tag that
clears the context sounds fishy to me...
All the best,
- Gabriel
On Jun 7, 10:52 am, Marco Louro wrote:
> 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 %}
> {{ label }}
> {% else %}
> {{ field.label_tag }}
> {% endif %}
>
>
> if there was a "label" variable in the context but not in the
> parameters, the code above would output the wrong values. There is one
> problem with not inheriting the context: {% csrf_token %} will fail.
>
> On Jun 7, 5:35 pm, Łukasz Rekucki wrote:
>
>
>
> > 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 tag? Why not just::
>
> > > {% 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.
>
> > --
> > Łukasz Rekucki
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 has gotten silly, though, since Russ (rightly) rejected it about 20 posts back ;-) All the best, - Gabriel On Jun 7, 9:47 am, Tom Evans wrote: > 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 almost everybody it seems. Is there any reason > >> > why this pattern hasn't been adopted by "django-admin.py startproject" > >> > yet? > > >> For one thing I'd say because most *really* large projects realize > >> this is a really bad way of handling settings. > > > Worse than one giant settings.py file? > > >> From my experiences > >> I'd say it makes a lot of sense to invert the dependencies, localized > >> settings require the global defaults, not the reverse. > > > The way I do it (and I'm assuming a lot of people do it this way too) > > is to have global settings tracked in their source control, while > > local_settings is something they have to write manually because it is > > untracked (due to having passwords and all). So it's way lore likely > > that the local settings file is missing instead of the global > > settings. Also, it really doesn't matter if one is more likely to be > > missing because both have to be present in order for the project to > > run. Does it really matter if the global or the local settings file > > raises the import error? > > Having posted the first way, I can appreciate that Alex's technique > gives slightly more control to the person writing the per-instance > config, without some of the cruft. For instance, my 'settings imports > settings_local' technique looks like this: > > try: > from settings_local import * > except: > # It's ok to not have any local settings. > pass > > # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists, > # so we can append any extra ones supplied in settings_local.py > if EXTRA_APPS: > INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS > > where as if settings.py is the 'local' file, with it loading default > settings from settings_default.py, it could look like this: > > from settings_default import * > INSTALLED_APPS = list(INSTALLED_APPS) + [ > 'some_app', > ] > > The project will always have default settings, so no need for a > try/except block, and we can directly manipulate settings without > having to pass around extra arguments, it's much neater. > > OTOH, it works exactly the same once deployed :) > > Cheers > > Tom -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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 %}
{{ label }}
{% else %}
{{ field.label_tag }}
{% endif %}
if there was a "label" variable in the context but not in the
parameters, the code above would output the wrong values. There is one
problem with not inheriting the context: {% csrf_token %} will fail.
On Jun 7, 5:35 pm, Łukasz Rekucki wrote:
> 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 tag? Why not just::
>
> > {% 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.
>
> --
> Łukasz Rekucki
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 almost everybody it seems. Is there any reason >> > why this pattern hasn't been adopted by "django-admin.py startproject" >> > yet? >> >> For one thing I'd say because most *really* large projects realize >> this is a really bad way of handling settings. > > Worse than one giant settings.py file? > >> From my experiences >> I'd say it makes a lot of sense to invert the dependencies, localized >> settings require the global defaults, not the reverse. > > The way I do it (and I'm assuming a lot of people do it this way too) > is to have global settings tracked in their source control, while > local_settings is something they have to write manually because it is > untracked (due to having passwords and all). So it's way lore likely > that the local settings file is missing instead of the global > settings. Also, it really doesn't matter if one is more likely to be > missing because both have to be present in order for the project to > run. Does it really matter if the global or the local settings file > raises the import error? > Having posted the first way, I can appreciate that Alex's technique gives slightly more control to the person writing the per-instance config, without some of the cruft. For instance, my 'settings imports settings_local' technique looks like this: try: from settings_local import * except: # It's ok to not have any local settings. pass # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists, # so we can append any extra ones supplied in settings_local.py if EXTRA_APPS: INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS where as if settings.py is the 'local' file, with it loading default settings from settings_default.py, it could look like this: from settings_default import * INSTALLED_APPS = list(INSTALLED_APPS) + [ 'some_app', ] The project will always have default settings, so no need for a try/except block, and we can directly manipulate settings without having to pass around extra arguments, it's much neater. OTOH, it works exactly the same once deployed :) Cheers Tom -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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.
what about:
{% include "some/template.html" with foo=bar baz=spam %}
=> adds varaibles 'foo' and 'baz' to current context
{% include "some/template.html" withonly foo=bar baz=spam %}
=> replaces current context with one having just 'foo' and 'baz'
--
Javier
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 pattern hasn't been adopted by "django-admin.py startproject" > > yet? > > For one thing I'd say because most *really* large projects realize > this is a really bad way of handling settings. Worse than one giant settings.py file? > From my experiences > I'd say it makes a lot of sense to invert the dependencies, localized > settings require the global defaults, not the reverse. The way I do it (and I'm assuming a lot of people do it this way too) is to have global settings tracked in their source control, while local_settings is something they have to write manually because it is untracked (due to having passwords and all). So it's way lore likely that the local settings file is missing instead of the global settings. Also, it really doesn't matter if one is more likely to be missing because both have to be present in order for the project to run. Does it really matter if the global or the local settings file raises the import error? -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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 tag? Why not just::
>
> {% 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.
--
Łukasz Rekucki
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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" with foo=bar baz=spam %}
?
Jacob
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: tests for ./manage.py validate
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 from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 startproject" > yet? > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > For one thing I'd say because most *really* large projects realize this is a really bad way of handling settings. From my experiences I'd say it makes a lot of sense to invert the dependencies, localized settings require the global defaults, not the reverse. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: tests for ./manage.py validate
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 ordering tests and this > should do the trick (if only the patch is provided too)? Sounds right to me. If you're validating that a particular model is ok, there should probably be an accompanying set of behaviors that also need to be tested; those tests can go wherever is appropriate for the feature you are testing (in this case, it sounds like one of the ordering-based modules, like modeltests/ordering, would be appropriate). Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: tests for ./manage.py validate
> 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 trick (if only the patch is provided too)? -- 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 from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: tests for ./manage.py validate
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 used on an > app and writes the result to a file. Could anyone give me some advice > on how to approach this problem? The tests for validate are pretty much all in the invalid_models model test. This test contains a bunch of model definitions that are known to be invalid (due to missing attribtues, conflicting field names etc). 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. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
tests for ./manage.py validate
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 a file. Could anyone give me some advice on how to approach this problem? -- 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 from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 abundantly clear. Cheers Tom -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 not requiring anything. You can set your own DISCOVERY_ORDER for your settings files. You can not use autodiscovery at all. I'm talking not about requirements but abilities. > Each of my deployments has its location specific configuration > deployed from administration RCS repo by cfengine to > settings_local.py, you can keep your 'state of the art'. How about development? Everyone's copy-pasting required settings from settings_local.py.template ? > >>> It is hardly a stretch to see how this kind of code could be extended >>> to try to import settings_auto or settings_default from each app in >>> installed apps. >> Sorry, I'm not native speaker. Can't understand what's "hardly a >> stretch" neither from context nor from dictionary. > > How about this - 'It is easy to see how this kind of code could be > extended to try to import settings_auto or ' I still don't understand what do you mean by this. Adding extra configuration files? You are still able to do this, nothing changed for you unless you want better autodiscovery. >> I am of control. That's why god gave us ability to override. >> It seems you are not aware what I suggest. > > I fully understand what you are suggesting, you cannot seem to > comprehend someone understanding what you are asking for, and > disagreeing with it. You said a point that wasn't correct. I doubted you understood what I suggested. > One of your use cases for this is to allow a pluggable application to > specify it's own database settings, which is unthinkable to me. Ok, don't think about that use case then. With every weapon you can shoot yourself in a foot. Can't you do "from yourapp.settings import *" and can't that settings.py set a database for you? > Setting up, configuring and allocating databases is work for the > project manager, not for the application developer. > > Similarly for any number of other settings that can have profound > effects on the functionality of the app, eg: > TEMPLATE_LOADERS > MIDDLEWARE_CLASSES > ROOT_URLCONF > INSTALLED_APPS > TEMPLATE_CONTEXT_PROCESSORS > > and any number of project specific settings that an application may be > unaware of. The role of configuring a project is for the project > manager, not for the application developer. This is hardly rocket > science! You have special person for configuring a project. I'm configuring my projects myself. You are happy with your "solution", I'm not. I'm proposing a change that will make both of us happy. I'm telling that every project configuration have the same steps in its development. single file -> two files -> machine dependent config files. The same is for the app development: no app-specific options -> app specific options This evolution does never change its direction. I suggest a solution that I think might spread. Of the problem which is already widespread, but for which every project config developer uses different solutions. The solution is not obligatory, it's optional. Like everything in Django. You will still be happy. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: {% include_partial %} template tag
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 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 {% with %} and {% include %} tags to do the same of course,
> but I think something like {% include_partial "forms/textfield.html"
> field=person_form.first_name label="First Name:" %} is much cleaner.
>
> This is similar to a rails tag called "render_partial" and there's a
> draft at http://gist.github.com/427116 based on
> http://freeasinbeard.org/post/107743420/render-partial-in-django
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Proposal: {% include_partial %} template tag
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 {% with %} and {% include %} tags to do the same of course,
but I think something like {% include_partial "forms/textfield.html"
field=person_form.first_name label="First Name:" %} is much cleaner.
This is similar to a rails tag called "render_partial" and there's a
draft at http://gist.github.com/427116 based on
http://freeasinbeard.org/post/107743420/render-partial-in-django
Thanks
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: modular django configuration
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 also want to change how everyone else does their deployments to your system? Why, because you implicitly trust them, should we allow pluggable application developers to define settings?! > > Btw, you are not yet using the "state of the art" python-based solution: > storing different local_settings in the version control system, > so do a dynamic import based on computer DNS name. > 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. Each of my deployments has its location specific configuration deployed from administration RCS repo by cfengine to settings_local.py, you can keep your 'state of the art'. >> It is hardly a stretch to see how this kind of code could be extended >> to try to import settings_auto or settings_default from each app in >> installed apps. > Sorry, I'm not native speaker. Can't understand what's "hardly a > stretch" neither from context nor from dictionary. How about this - 'It is easy to see how this kind of code could be extended to try to import settings_auto or ' > I am of control. That's why god gave us ability to override. > It seems you are not aware what I suggest. I fully understand what you are suggesting, you cannot seem to comprehend someone understanding what you are asking for, and disagreeing with it. One of your use cases for this is to allow a pluggable application to specify it's own database settings, which is unthinkable to me. Setting up, configuring and allocating databases is work for the project manager, not for the application developer. Similarly for any number of other settings that can have profound effects on the functionality of the app, eg: TEMPLATE_LOADERS MIDDLEWARE_CLASSES ROOT_URLCONF INSTALLED_APPS TEMPLATE_CONTEXT_PROCESSORS and any number of project specific settings that an application may be unaware of. The role of configuring a project is for the project manager, not for the application developer. This is hardly rocket science! Cheers Tom -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
