Re: override_settings with dynamic model creation
Hi Alisue, Django already have a way to create models only for tests: put model definitions to tests.py. Such models will be available in tests but won't be created with ./manage.py syncdb. вторник, 28 февраля 2012 г. 9:11:25 UTC+6 пользователь Alisue написал: > > (2012年02月28日 01:34), Florian Apolloner wrote: > > Hi, > > > > On Monday, February 27, 2012 2:53:37 PM UTC+1, Alisue wrote: > >> > >> But I found that ``override_settings`` is available in dev version of > >> django. So I just wonder that if official django's > >> ``override_settings`` support dynamic model creation. > > > > > > ``override_settings`` does exactly what the name says: It overrides > > settings -- there is nothing special done for models etc, it's just a > > convenient way to change settings and restore them back later on. > > > > Cheers, > > Florian > > > So you mean that ``override_settings`` should have minimum feature and > should NOT do complicated things? That makes sense but I think django > SHOULD HAVE some features for creating tables dynamically in test and > when user override ``INSTALLED_APPS`` that mean the user want to use > that app in test (or whatever) so I suggested. > > Well then how do you think that django's ``TestCase`` have > ``required_apps`` attribute which is used to add required > apps and create tables of the apps? In that case, ``override_settings`` > is not used for overriding ``INSTALLED_APPS`` and should raise warning. > > Thanks. > Alisue > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/URPNq780bfoJ. To post to this group, send email to django-developers@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: override_settings with dynamic model creation
Well really? I didn't notice. Is there any documentation for that or not available yet? I couldn't find any documentations or source code for it. Anyway that is really nice :-) Thanks! Alisue (2012年02月28日 18:08), Mikhail Korobov wrote: > Hi Alisue, > > Django already have a way to create models only for tests: put model > definitions to tests.py. Such models will be available in tests but won't > be created with ./manage.py syncdb. > > вторник, 28 февраля 2012 г. 9:11:25 UTC+6 пользователь Alisue написал: >> >> (2012年02月28日 01:34), Florian Apolloner wrote: >>> Hi, >>> >>> On Monday, February 27, 2012 2:53:37 PM UTC+1, Alisue wrote: But I found that ``override_settings`` is available in dev version of django. So I just wonder that if official django's ``override_settings`` support dynamic model creation. >>> >>> >>> ``override_settings`` does exactly what the name says: It overrides >>> settings -- there is nothing special done for models etc, it's just a >>> convenient way to change settings and restore them back later on. >>> >>> Cheers, >>> Florian >>> >> So you mean that ``override_settings`` should have minimum feature and >> should NOT do complicated things? That makes sense but I think django >> SHOULD HAVE some features for creating tables dynamically in test and >> when user override ``INSTALLED_APPS`` that mean the user want to use >> that app in test (or whatever) so I suggested. >> >> Well then how do you think that django's ``TestCase`` have >> ``required_apps`` attribute which is used to add required >> apps and create tables of the apps? In that case, ``override_settings`` >> is not used for overriding ``INSTALLED_APPS`` and should raise warning. >> >> Thanks. >> Alisue >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Revisiting multiline tags
On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/23/2012 11:29 PM, Russell Keith-Magee wrote: > > This thread contains 6 people expressing support for this change, and > > 2 against (a BDFL, a core developer) -- and you can add me to the -0 > > FWIW, I'd forgotten how painful the single-line restriction was the last > time I had to work on internationalized templates using blocktrans. The > presented use cases have me thoroughly convinced that this is an > unreasonable restriction on template authors, and I'd be +1 on lifting it. If the translation tags are pretty much the only things that would really benefit from multi-line tags (and they certainly seem to be the focus here), surely that's an indication that they're the problem, not the unavailability of multi-line tags? Do all the arguments really have to be within the single tag? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: Revisiting multiline tags
On Feb 28, 11:05 pm, Nick Phillips wrote:
> On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
>
> > On 02/23/2012 11:29 PM, Russell Keith-Magee wrote:
> > > This thread contains 6 people expressing support for this change, and
> > > 2 against (a BDFL, a core developer) -- and you can add me to the -0
>
> > FWIW, I'd forgotten how painful the single-line restriction was the last
> > time I had to work on internationalized templates using blocktrans. The
> > presented use cases have me thoroughly convinced that this is an
> > unreasonable restriction on template authors, and I'd be +1 on lifting it.
>
> If the translation tags are pretty much the only things that would
> really benefit from multi-line tags (and they certainly seem to be the
> focus here), surely that's an indication that they're the problem, not
> the unavailability of multi-line tags?
>
> Do all the arguments really have to be within the single tag?
For possible ideas:
{% blocktrans %}
{% variables a=1, b=2, c=3 %}
{% variables d=4, e=5, ...
This is my example translatable text. ({{a}}).
{% endblocktrans %}
Same for with and include. The variables tag would be only allowed
directly after a variables tag, or after with, include or blocktrans
tag. It might be hard to implement efficiently, so that might be
enough to stop this idea.
Or how about allowing multi-line tags only for with, blocktrans and
include tags? Maybe it is just the "with" which is problematic, be it
alone or inside another tag. I don't know if it would be possible to
implement a rule of 'after "with" you are allowed to change lines in
the tag'. The above would then become:
{% blocktrans with
a=1, b=2, c=3,
d=4, e=5, ...
%}
I don't know if these solutions have much potential. But I do think
the problem is a real one for those who happen to be hit by this
problem. So, it would be nice to find some solution.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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: Newline stripping in templates: the dnl way
> Django templates are useful (and used) for all sorts of text-based
> formats. For some of these, an exact control over whitespace is needed
> throughout the entire file (eg. text/plain),
Agreed. When I started using Django templates I was very surprised at
the output I was seeing.
After a while I realised that the thing that suprised me was that
newlines were being output for what I considered to be just
'directives' -- that is, lines that contained tags, not content. For
example, {% if %} and {% endif %} tags on lines by themselves.
Honestly, my use case then was to make my HTML look pretty, so was
able to let it go pretty easily. Recently however I used the template
system to produce an email with a textual pricing table, and there the
lack of easy whitespace control hurt there.
Would it be feasible to add some logic, something along the lines of:
"Template lines containing just tags with no literal content do not
produce a line in the output (unless of course the tag itself
produces one)"
After all, new lines are easy to add, but currently painful to suppress...
Cheers,
Leon
--
Leon Matthews BSc
Technical Director, Messiah Ltd.
work: http://messiah.co.nz/
home: http://lost.co.nz/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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: Newline stripping in templates: the dnl way
On Feb 29, 8:15 am, Leon Matthews wrote: > Would it be feasible to add some logic, something along the lines of: > > "Template lines containing just tags with no literal content do not > produce a line in the output (unless of course the tag itself > produces one)" I believe that is what has been suggested, and tickets produced by SmileyChris and worked on by others to that end, at https://code.djangoproject.com/ticket/2594 The ticket is still accepted (and is now 6 years old), and the consensus from this thread now appears to be that the "dnl" and multi- line comment solutions put forward here are not preferred. I think the next step is for any interested parties to look at the latest patches on that ticket, update them for trunk and make sure they still work, have the required tests and/or docs, and try to get it committed. Cheers. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
make the File Storage API works with a file-like object instead of the Django File object.
Hi, The File Storage API only works with the Django File object (https:// docs.djangoproject.com/en/1.3/ref/files/storage/ ; https://docs.djangoproject.com/en/1.3/ref/files/file/). Wouldn't it be a good idea to make a Django file-like object instead and make the Storage API works with it ? That way we could use the current Django File object when it is real files but also use a "remote" file object like the urllib2.urlopen returns. What do you think ? Best, Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: make the File Storage API works with a file-like object instead of the Django File object.
You can create a Django file object from any file-like object just by passing it to the constructor. django.core.files.File(my_file_like_object) This is basically what all the storage backends do where there is an existing file object from whatever source, and what you have to do if you want to save an existing file to a FileField. - ojno On 28 February 2012 22:28, Michael wrote: > Hi, > > The File Storage API only works with the Django File object (https:// > docs.djangoproject.com/en/1.3/ref/files/storage/ ; > https://docs.djangoproject.com/en/1.3/ref/files/file/). > Wouldn't it be a good idea to make a Django file-like object instead > and make the Storage API works with it ? > That way we could use the current Django File object when it is real > files but also use a "remote" file object like the urllib2.urlopen > returns. > > What do you think ? > > Best, > Michael > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@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. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: make the File Storage API works with a file-like object instead of the Django File object.
This ticket is related to the issue: https://code.djangoproject.com/ticket/16946 -Paul On Tue, Feb 28, 2012 at 3:29 PM, Jonathan French wrote: > You can create a Django file object from any file-like object just by > passing it to the constructor. > > django.core.files.File(my_file_like_object) > > This is basically what all the storage backends do where there is an > existing file object from whatever source, and what you have to do if you > want to save an existing file to a FileField. > > - ojno > > > On 28 February 2012 22:28, Michael wrote: >> >> Hi, >> >> The File Storage API only works with the Django File object (https:// >> docs.djangoproject.com/en/1.3/ref/files/storage/ ; >> https://docs.djangoproject.com/en/1.3/ref/files/file/). >> Wouldn't it be a good idea to make a Django file-like object instead >> and make the Storage API works with it ? >> That way we could use the current Django File object when it is real >> files but also use a "remote" file object like the urllib2.urlopen >> returns. >> >> What do you think ? >> >> Best, >> Michael >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@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. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Jquery library update in django 1.4
hi, is it possibile to upgrade the jquery library in admin to the lastest version with the now django 1.4? for what i've seen there is just one little bug when you use the select all checkbox in admin changelist, all other javascript works out of the box -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
