Re: Proposal - admin actions with no elements selected
Thanks for the reply. If it wouldn't take too much time, can you please point me to those discussions? All I was able to find was that thread http://groups.google.com/group/django-developers/browse_thread/thread/1edf77c9c8b1101d/06d4775747a5a127?lnk=gst&q=admin+action+selected#06d4775747a5a127 with a message of yours. If that's counter intuitive, what is the preferred way to include such actions? On Mar 1, 5:26 pm, Alex Gaynor wrote: > On Mon, Mar 1, 2010 at 12:23 AM, George Karpenkov > > > > > > wrote: > > Hi there, > > > Currently, if no elements are selected, any action selected in the > > admin interface will not fire. > > > However, sometimes it is useful to create actions which do not require > > any elements to be selected - ie > > > x removing all elements > > x drag-n-drop reordering of all elements > > x arranging elements into some sort of tree structure > > > and etc. - essentially, actions which work on all / certain subset of > > elements, which is defined in the logic of the action (one more > > example - "delete all unpublished articles") > > > Wouldn't this be useful? > > > Regards, > > George > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > It was an intentional design decision to not support admin actions > with 0 items. Having 2 separate sets of functionality (those that > operate on selected items, and those that operate on all, none, or > something else entirely) in a single UI element was deemed to be very > counter intuitive. If you search this list you'll see that this has > been discussed several times. > > 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 - admin actions with no elements selected
On Mon, Mar 1, 2010 at 6:59 AM, George Karpenkov wrote: > Thanks for the reply. > > If it wouldn't take too much time, can you please point me to those > discussions? > > This ticket is one I recall: http://code.djangoproject.com/ticket/10768 Karen -- 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: dbsettings, and user configurable app settings
> I've never understood the desire for more magical behavior here. My > apps have a settings.py that imports django.conf.settings and provides > any necessary defaults for unset settings; the rest of my app imports > from there. Works great, easy to look and see what settings my app > consumes and what defaults they have. I don't see what advantages a > more complex system would provide. Example > here:http://bitbucket.org/carljm/django-adminfiles/src/tip/adminfiles/sett... I am not necesary advocating magic. But the need for a more robust (or lets say, any) configuration management exists for many. I think the problem stems when you when apps become more modular, and your projects more complex, people start to ask for a more robust configuration. I am talking about +30~50 apps. that's why you have stuff like buildout, registries, etc... I am very familiar with your setup, and its the best one in use I have seen. but it has several shortcomings. I think django should stay "lean" and flexible, and should avoid bloat, that doesn't mean we shouldn't be discussing ways to improve it, and as django grows it will face the inevitable challenge of catering different uses. mingus creator discusses shortly the the config problem in django advent:http://djangoadvent.com/1.2/everything-i-hate-about-mingus/ at work I use plone as a base and django for very lean project/apps, privately using django for a lot of lean stuff. but django-mingus is the first project that I have used the leverages the most reusable apps (havent used pinax nor satchmo yet). And I am working on making it a resuable app itself. one of the few times that I wished django was more plonish. -- 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.
problem in modeladmin response_action
Hi there, I just switch from 1.2 beta 1 to svn version and the ModelAdmin.response_action is not working as before. For example it does not delete objects when confirming a bulk deletion. The problem seems to be in the beginning of the function if 'index' not in request.POST: return None By commenting the above, the problem seems to disappear. Best Luca -- 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: problem in modeladmin response_action
On Mon, Mar 1, 2010 at 9:47 AM, Luca Sbardella wrote: > Hi there, > > I just switch from 1.2 beta 1 to svn version and the > ModelAdmin.response_action is not working as before Yes, this has been reported at least twice in the tracker (see http://code.djangoproject.com/ticket/12962) and at least once before on this list. Karen -- 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: Deprecating cmemcache, adding pylibmc
On Sun, Feb 28, 2010 at 11:40 PM, Jacob Burch wrote: > Thanks all for the helpful discussion here. From the sounds of thing, > my course of action will be: > > 1) Get a patch that throws a FutureDeprecationWarning when cmemcache > is used + Change of the docs to note the coming deprecation of > cmemcache > 2) Begin working on a more involved patch that hopefully get slated in > for 1.3. Yeah, that sounds right, and thanks. Also, a step 2.5, if you'd like, would be to write a tiny app on pypi that enabled the use of pylibmc via an external cache backend. We could point to it in the deprecation notes when we explain why cmemcache is being deprecated. 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.
Django 1.2, ManyToMany relations and legacy database support
Hi, I gave Django 1.2 a go but I had some issues with legacy database support. I have several ManyToMany relations with an intermediate model that doesn't have an id field (only 2 fields pointing on each table). With Django 1.1, I abused this snippet : http://www.djangosnippets.org/snippets/962/ As it wouldn't work with Django 1.2, I tried to got within the related.py file to adapt it but I'm a bit lost and would need some advices. My first though was to hack the create_many_to_many_intermediary_model function in order to get the intermediate class to have ForeignKeys with the right column name (with db_column) but that clearly isn't enough to make it work correctly. Now, I'm a bit lost as I don't understand how the ManyToManyField becomes a ReverseManyRelatedObjectsDescriptor... Could someone point me a direction in order to get an equivalent to db_column for the intermediate class in a many to many relation ? Regards, Xavier. -- 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: Django 1.2, ManyToMany relations and legacy database support
Hi Xavier -- This is a question better asked on django-users -- django-developers is for discussion of the development of Django itself, not usage questions. As a brief answer to your question, you'll want to take a look at defining a custom intermediary model: http://docs.djangoproject.com/en/dev/topics/db/models/#extra-fields-on-many-to-many-relationships Thanks, 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: Django 1.2, ManyToMany relations and legacy database support
Hi Jacob, Thanks for your answer. I already gave intermediate models a look but I'm not feeling like defining a dozen useless model - no added value - and loosing a couple of API calls are worth just because my fields are labeled "id_fieldname" instead of "fieldname". Sorry for the annoyance. Xavier. -- 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: IfEqualNode is missing a get_nodes_by_type method
On Feb 27, 3:06 am, Russell Keith-Magee
wrote:
> I'm a little confused by this ticket.
>
> The original report was about something that is clearly a bug -- the
> inconsistency between block handling for {% if %} and {% ifequal %}.
> I'm 100% in agreement that this inconsistency should be fixed.
>
> The thing is - it has been. The tests in the patch on #6510 all pass
> on current trunk. The refactoring that was required for template
> caching has evidently cleaned up this issue - at least enough to
> correct the original test case.
Yes, the recent changes with BlockContext have hidden the error from
the testcases (and even my old test cases in the initial patch).
The inconsistency is still there -- and also a problem for {%
ifchanged %} I just noticed.
I have uploaded a new patch with a much simpler test case testing for
the underlying problem across all tags which have nodelist attributes
named something other than the standard "nodelist".
--
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: Issues surrounding IDN validation and URLs in general
2010/2/28 Ulrich Petri :
> ~/ python2.6
> Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
from urllib2 import urlopen
urlopen('http://пример.испытание/')
> >
Yeah, it seems to be working on MacOS, but why it is not working on my
linux system?
$ python2.6
Python 2.6.4+ (r264:75706, Feb 16 2010, 00:09:58)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib2 import urlopen
>>> urlopen('http://пример.испытание/')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/lib/python2.6/urllib2.py", line 409, in _open
'_open', req)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 1161, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.6/urllib2.py", line 1136, in do_open
raise URLError(err)
urllib2.URLError:
> This isn't a IDN problem it's a "normal" python unicode string handling
> problem. What is the locale on your System?
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Have a nice day,
Nikolay.
--
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.
