Re: Ticket #5333: add an assertContext method to Django's TestCase
Russell Keith-Magee wrote: > On 9/5/07, Gary Wilson <[EMAIL PROTECTED]> wrote: >> Gary Wilson wrote: >>> Russell then added the comments: >>> - >>> My hesitation here (and the reason I didn't include a 'context assert' in >>> the >>> first place) is that assertContext does an Equals test, but doesn't provide >>> a >>> way to do any other assertion - NotEquals?, True, False, LessThan?, etc. We >>> could get around this by adding assertContextEquals, assertContextNotEquals, >>> and so on, but that is really just duplicating the underlying assertion API. >>> This is certainly possible, but I'm not convinced it is the best approach. In my implementation of assertContext, I pretty much followed what was going on in assertFormError; however, I realized while writing some tests today at work that yes, it would be nice to have all the other assertions available. So whatever gets decided on for an assertContext solution should probably also get applied to assertFormError, IMHO. >>> An alternate approach would be to provide a utility function to get the >>> value >>> of a context variable from the list of contexts in a response. This would >>> allow the use of all the standard assert methods. However, I'm not entirely >>> sure where such a utility function should go. Putting it on the TestCase? >>> itself rubs me the wrong way. >>> - >> What would happen in the case where the same variable name is used in >> multiple >> contexts with different values in each context? > > Valid point - however, in practice, the same context is passed to > multiple templates. There are some edge cases (e.g., a view with two > calls to render_to_template) where this isn't the case, but I wouldn't > consider them to be the common case. Template tags that make use of a template maybe a more common case, but it's probably better to be testing those at a lower level anyway. > I suppose we could have the context-extracting helper method raise an > exception in the case of multiple values, or return a tuple in the > case of multiple values. However, I'm not particularly enamoured with > either of those suggestions. What if we make make response.context always just a single item of the first context used for rendering (and move the storage of the full list of contexts to response.contexts). The majority of the time, you're wanting to test just that first context anyway. The context(s) used for extended templates is uninteresting since it's the same as the outer context. So this would allow for all the existing assertions to be used: self.assertEqual(response.context['title'], 'hello world') self.assertNotEqual(response.context['title'], 'goodbye world') ... And if we want, we can add the assertContext (or assertContextContains) for when you need to go deeper than the first context. But in this case, you would be limited to just checking that _any_ context used contains the specified context variable with the specified value (the way it's coded in the patch). Test would look like: self.assertContextContains(response, 'title', 'hello world') I think this would do a good job of making the simple case simple and the complex case possible. Thoughts? Gary --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django on jython (new version)?
Hi All, I've only just signed up to this group so i'm hoping my Re: subject links into the original chat about this. Because i love the ease of development that django offers, i've been moving bits of django code to get an autoreloading jython service running. After finding a few other blogs for other people trying to move django to jython, i decided to post my work here so we might be able to merge our efforts. (maybe we could get some svn space somewhere) here is my trac page for my changes https://dev.archer.edu.au/projects/kepler/log/jython-django (changeset 124 is the most interesting) the changesets are a bit messed up since i have not updated all my files to reflect the current django-svn. below i'll post a description of all the things i've done so far for all who're interested. cheers --Tristan just a quick note: i'm very new to python. I've only been programming in it for a few weeks now. so feel free to throw constructive criticisms at my code :) things i haven't done: since i'm not interested in using the models package just yet, i haven't moved any of that code to jython. but Leo Soto seems to be doing a fine job at this. because of this i've had to work around some of the references to the models package (ie. when the server validates the models) major things i've done include: ** getting the autorealod module to work. this has been an interesting task. I started off by replacing the spawnve with java.lang.Runtime calls to spawn the new task. For which i has to spawn a few other threads to read the process's stdout and err. looking at the code as i type this i realise i can remove the loop starting at line 111, i think that's just remains of some debuging :). good how these things make you re look over old code :). also the sys.executable call in jython doesn't work the same as it does in python, so i had to dodgy that up a bit (if anyone starts their jython with a name other than 'jython' it will break this :)) i've also had to work around a jython bug (i've still got to find out if it's a known bug) with the modules. hence the try: except: in lines 53:81. I've just spent the last hour trying to reproduce the jython bug, for anyone interested, https://dev.archer.edu.au/projects/kepler/wiki/Notes#myjythonbug . this is just a temporary spot till i find the respective jython ticketing system to throw it into :) now where was i... So, After these changes, the reloader works as expected. The only issue is that it's not as quick as the python one, since jython has quite a hefty startup time. so there's a bit of waiting around sometimes for the server to start up. but it's still completely automatic, which is excellent! ** automatic java library pathing because i didn't want to have to manually load any new jars i want to use in my jython app into the sys.path, i added a LIB_DIRECTORY setting to the settings module. this is used in the setup_environ function (core/management/__init__.py lines 148:153) which lists the directory and adds all the jars it finds to sys.path. this probably needs a bit more work but no use cases have come up for me yet, so it'll stay like this till they do. ** readline in the jython console so manage.py shell works this is more of a jython specific thing than django but i've just been messing with rlcompleter trying to tab completion in the jython console. i've got it working satisfactorily, but it still borks out every now and then. what i'm currently messing with: the simplejson modules. if a dictionary has javainstance objects in it, the simplejson encoder doesn't know what to do with it. i'm trying to work around this. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: not ascii problem in forms with SELECT box
Please see my comment below... On Sep 13, 2007, at 2:46 AM, audial wrote: > > Hello all! > > latest version of django ( trunk ), oracle 9.2.0.6. > > i got some stupid error during entering the data in form's SELECT box. > later i set this TRY block to the FORCE_UNICODE function ( django/ > utils/encoding.py ) > > def force_unicode(s, encoding='utf-8', strings_only=False, > errors='strict'): > """ > Similar to smart_unicode, except that lazy instances are resolved > to > strings, rather than kept as lazy objects. > > If strings_only is True, don't convert (some) non-string-like > objects. > """ > if strings_only and isinstance(s, (types.NoneType, int)): > return s > try: > if not isinstance(s, basestring,): > if hasattr(s, '__unicode__'): > s = unicode(s) > else: > s = unicode(str(s), encoding, errors) > elif not isinstance(s, unicode): > s = unicode(s, encoding, errors) > except: > return s.__str__ This line should return s.__str__() Chaiwat.S --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Re The sprint
Thanks for the input and the info. I'll have a look at those issues and hopefully get them sorted before the sprint. Ben On 12/09/2007, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 9/12/07, Ben Ford <[EMAIL PROTECTED]> wrote: > > Thanks for the responses guys. > > Russ what is your feeling about getting multi-db into the repo so that > > people can then use it? I'm happy to do the work that I mentioned above > in > > merging the branch up to date to the point of the backend refactor in > trunk, > > and after that to start exploring re-factoring the multi-db to leverage > some > > of the later changes in trunk. But I'd really like to ensure that I can > send > > the patch to someone and thence get it into the repo. > > Is the diff on #4747 the latest version of the patch that you have? If > so, I have a few reservations about applying this diff. > > Just taking the first few changes in the patch (django/test/utils.py) > as an example: > - The very first change is a multi-line import, which, while legal, > isn't good form. > - The next block of changes involve introducing an > instrumented_test_iter_render, which doesn't exist in the current > trunk. > - The next change (around line 117 of the new version) hard codes the > location of a database file in your personal home directory. > > I haven't worked through the full 200k patch, but if the first few > changes are any indication, there is still work to do before this gets > merged. > > There are two sets of changes that need to be applied: merges from > trunk, and new code. These patches need to be kept separate for commit > purposes, and each new idea should be a separate patch, committed > separately. From all appearances, the patch on #4747 is a mix of both > merge changes and new features. > > I'm happy to apply any patches that are raw merges from trunk. If you > also have some fixes/enhancements that go beyond trunk merges, I'm > happy to look at them, although they will have to meet a basic quality > standard. > > > Once we're to that > > point maybe we can re-explore the possibilities of me having commit > access > > to the branch and acting as maintainer. > > That's an issue you'll have to take up with Jacob and Adrian - they're > the ones that control access to SVN. However, as I have said many > times before, access to the repository is generally restricted to > those that have an established track record. > > Regarding using some sort of distributed version control - there is a > semi-official Mercurial repository available; it's been mentioned in > the developers list a few times. > > Yours, > Russ Magee %-) > > > > -- Regards, Ben Ford [EMAIL PROTECTED] +628111880346 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms: custom error messages
On Sep 12, 3:42 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > So whilst adding it is consistent, it's not really a common way to use > translation and shouldn't be necessary for that patch. True, I was getting confused about __all__ Anyway, the ticket now contains full tests and docs. Feel free to look it over ;) (I'm getting amped for the sprint) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [Proposal] i18n blocktrans semantics & syntax change
On Wed, 2007-09-12 at 23:10 +0200, Tomas Kopecek wrote:
> Hi,
> I've implemented blocktrans in slightly different syntactical/semantical
> manner. Look at the following examples:
>
> {% blocktrans %}
> text {{var}}
> {{var|filter}}
> {% endblocktrans %}
>
> and plural variant:
>
> {% blocktrans count any_string|length as count %}
> singular variant {{count}}
> {% plural %}
> plural variant {{count|intcomma}}
> {% endblocktrans %}
>
> Briefly it means, that blocktrans accept _only_ 'count var as var_name'
> clause and does not need to declare block variables. Inside block is
> allowed anything, what is allowed in other blocks. So you can use any
> number of filters.
The standard argument against allowing arbitrary constructs inside the
translation block (things like {{var|filter}}) is that translators have
to type that string *exactly* into their translation in order for it to
appear. Since those strings can get quite complex, it's putting a burden
on translators that can be avoided by only allowing simple variables or
aliases in there. Basically, it's a way to reduce errors.
I'm not in favour of allowing more complex stuff inside for that reason.
I don't understand how plural is meant to decide *what* is the thing to
use when deciding if something is plural. Remember that there can be
multiple aliases in a blocktrans block. Unless I'm missing something
(quite possible), it looks like this only works when you have a single
alias in there. Is that correct?
We do need to work out some ways of allowing plural forms a bit more
easily. There was a discussion on this list a few months back where some
people suggested some alternatives, but nothing really pretty fell out,
so there's still work to be done there. However, I'm not sure this is a
solution, either, since it's a bit restrictive.
Regards,
Malcolm
--
Why be difficult when, with a little bit of effort, you could be
impossible.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
[Proposal] i18n blocktrans semantics & syntax change
Hi,
I've implemented blocktrans in slightly different syntactical/semantical
manner. Look at the following examples:
{% blocktrans %}
text {{var}}
{{var|filter}}
{% endblocktrans %}
and plural variant:
{% blocktrans count any_string|length as count %}
singular variant {{count}}
{% plural %}
plural variant {{count|intcomma}}
{% endblocktrans %}
Briefly it means, that blocktrans accept _only_ 'count var as var_name'
clause and does not need to declare block variables. Inside block is
allowed anything, what is allowed in other blocks. So you can use any
number of filters.
In plural variant remains 'count var as var_name' mainly because of
allowing filters in 'var' part. Maybe it could be clearer to deny
filters and allow only {% blocktrans count var_name %} syntax, which
means that var_name is used for determining s/pl. This variable would
still be accessible in the block as 'var_name'.
I've dig mail list for reasons why were put restrictions on variables
inside block and I've found post saying, that is needed according to
xgettext semantics. I'm no xgettext expert but as I see, deciding on
which form (pl.,sing.) is used is determined by blocktrans itself. So I
think, that such change is not problematical and a few test I've made
says the same. So if there is no serious argument aagainst, I would vote
for changing semantics to be more corresponding to other block tags and
to be little bit more user friendly.
So, questions:
a) Is there any argument against?
b) Which variant for plural decision is more appropriate frm django
design view?
P.S. Nothing looks more horrible than two paragraphs of mostly db
numbers in blocktrans with _very_ long {% blocktrans ... %} declaration.
I also think, that it is againstr DRY principle.
--
Tomas Kopecek
e-mail: permonik at mesias.brnonet.cz
ICQ: 114483784
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: permission_required sends user to login, even if already logged in
I guess I should know what a 403 error is, shouldn't I? :-) Thanks a million, Collin. That was exactly what I was looking for. On Wed, 2007-09-12 at 12:28 -0700, Collin Grady wrote: > Todd O'Bryan said the following: > > Does anyone else wish that there were a setting for a PERMISSION_DENIED > > page that the permission_required decorator could send users who are > > already logged in to, rather than sending them to the login page? > > > > I'd still like users who aren't logged in to be sent to the login page. > > http://www.djangosnippets.org/snippets/254/ ? :) > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: per object permissions in admin using newforms-admin
Yes, you're right. Renamed it to FieldLevelPermissionAdmin by the way. 2007/9/12, andybak <[EMAIL PROTECTED]>: > > I think that must be Yuri's own work actually. Yuri? > > On Sep 12, 1:42 pm, RKnobelspies <[EMAIL PROTECTED]> wrote: > > You might also want to check out this snippet: > > > > RowLevelPermissionsAdmin > > http://www.djangosnippets.org/snippets/414/ -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
not ascii problem in forms with SELECT box
Hello all! latest version of django ( trunk ), oracle 9.2.0.6. i got some stupid error during entering the data in form's SELECT box. later i set this TRY block to the FORCE_UNICODE function ( django/ utils/encoding.py ) def force_unicode(s, encoding='utf-8', strings_only=False, errors='strict'): """ Similar to smart_unicode, except that lazy instances are resolved to strings, rather than kept as lazy objects. If strings_only is True, don't convert (some) non-string-like objects. """ if strings_only and isinstance(s, (types.NoneType, int)): return s try: if not isinstance(s, basestring,): if hasattr(s, '__unicode__'): s = unicode(s) else: s = unicode(str(s), encoding, errors) elif not isinstance(s, unicode): s = unicode(s, encoding, errors) except: return s.__str__ else: return s - it says that not literal could not be as unicode() param, and that i got an model instance there. so, i try to put __str__() there. Now i get all i need, KOI8-R literals in SELECT box, but they are not sorted =\ how could i get it? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: permission_required sends user to login, even if already logged in
Todd O'Bryan said the following: > Does anyone else wish that there were a setting for a PERMISSION_DENIED > page that the permission_required decorator could send users who are > already logged in to, rather than sending them to the login page? > > I'd still like users who aren't logged in to be sent to the login page. http://www.djangosnippets.org/snippets/254/ ? :) -- Collin Grady --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Let's schedule a Django sprint
On 9/12/07, Don Spaulding <[EMAIL PROTECTED]> wrote: > I know it's kind of late notice, but do we need to do anything to let > Google know we are coming besides sign up on the wiki page? Also, > what do we need to bring besides a machine? I'd be willing to provide > snacks/beverages if they aren't already taken care of. I'm taking care of communication with Google and have sent them the list of names on the wiki page as of yesterday afternoon. It looks like your and Jeff Gibson's names weren't on the list at that point, but I'll grandfather you in. The list for Google Chicago is now final. Don, I will send you more logistical information off-list. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Let's schedule a Django sprint
On Sep 7, 11:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > Google Chicago is for sure, but I'm not sure yet about Mountain View. I know it's kind of late notice, but do we need to do anything to let Google know we are coming besides sign up on the wiki page? Also, what do we need to bring besides a machine? I'd be willing to provide snacks/beverages if they aren't already taken care of. Or do we get to feel like Google employees for the day and eat M till we're sick? :-) Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Re The sprint
On 9/12/07, Ben Ford <[EMAIL PROTECTED]> wrote: > Thanks for the responses guys. > Russ what is your feeling about getting multi-db into the repo so that > people can then use it? I'm happy to do the work that I mentioned above in > merging the branch up to date to the point of the backend refactor in trunk, > and after that to start exploring re-factoring the multi-db to leverage some > of the later changes in trunk. But I'd really like to ensure that I can send > the patch to someone and thence get it into the repo. Is the diff on #4747 the latest version of the patch that you have? If so, I have a few reservations about applying this diff. Just taking the first few changes in the patch (django/test/utils.py) as an example: - The very first change is a multi-line import, which, while legal, isn't good form. - The next block of changes involve introducing an instrumented_test_iter_render, which doesn't exist in the current trunk. - The next change (around line 117 of the new version) hard codes the location of a database file in your personal home directory. I haven't worked through the full 200k patch, but if the first few changes are any indication, there is still work to do before this gets merged. There are two sets of changes that need to be applied: merges from trunk, and new code. These patches need to be kept separate for commit purposes, and each new idea should be a separate patch, committed separately. From all appearances, the patch on #4747 is a mix of both merge changes and new features. I'm happy to apply any patches that are raw merges from trunk. If you also have some fixes/enhancements that go beyond trunk merges, I'm happy to look at them, although they will have to meet a basic quality standard. > Once we're to that > point maybe we can re-explore the possibilities of me having commit access > to the branch and acting as maintainer. That's an issue you'll have to take up with Jacob and Adrian - they're the ones that control access to SVN. However, as I have said many times before, access to the repository is generally restricted to those that have an established track record. Regarding using some sort of distributed version control - there is a semi-official Mercurial repository available; it's been mentioned in the developers list a few times. 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: per object permissions in admin using newforms-admin
I think that must be Yuri's own work actually. Yuri? On Sep 12, 1:42 pm, RKnobelspies <[EMAIL PROTECTED]> wrote: > You might also want to check out this snippet: > > RowLevelPermissionsAdminhttp://www.djangosnippets.org/snippets/414/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: per object permissions in admin using newforms-admin
You might also want to check out this snippet: RowLevelPermissionsAdmin http://www.djangosnippets.org/snippets/414/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [Fwd: Memory leaks]
> I've got some time for testing and results are that without DEBUG is no > memory overhead. But I still wonder that if I delete connection.queries > in every cycle, why memory consumption still grows. What other > structures are created in DEBUG mode? Simple 'grep DEBUG' showed nothing > really interesting in ORM layer. > I also had a problem with memory leaks and found that in addition to the query log, any errors were also being kept: import warnings warnings.resetwarnings() --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signals in ManyRelatedManager
On 9/12/07, Ludovico Magnocavallo <[EMAIL PROTECTED]> wrote: > The only advantage I see in adding signals (but I'm not an expert of > Django internals) is that it's pretty painless as it's five-lines patch, > and it leaves all the other code unchanged. I'm definitely still considering signals, because it is a simple way to add this functionality. However, there are some other things that m2m relationships can benefit from that I'd like to include at the same time if at all possible. > A possible short-term solution could be to apply the signals patch now, > then when/if you implement mix-ins, add a custom one that uses signals > so that people relying on them do not have to modify their code, but can > simply pass the mix-in to the M2M field. They will then be able to > gracefully migrate to a (possibly) cleaner solution writing their own > mix-in. That's a possibility, but not what I'd really like to do if I can at all avoid it. This is a new feature we're talking about, not an existing bug, so I think we can afford to take the time to do it right the first time. You're more than welcome to patch your own, since you're already willing to change it up when some kind of official support lands, but I'm not thrilled about asking other people to do that. -Gul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signals in ManyRelatedManager
Marty Alchin wrote: > I've come up with a considerably different approach to this, which > offers more flexibility, and also solves a problem I've had when it > comes to ManyToManyField. Basically, instead of dealing with signals, > and worrying about pre/post and whether or not you can prevent stuff, > I broke out some bits of ManyRelatedManager into a separate mix-in, > which can be subclassed. [snip] Sounds like a very flexible approach, definitely more easy to use than signals. The problem you mention with having to check which side of the relationship you are working on in the custom mixin does not apply to signals, as the sender objects are different and you can register different functions for each one of them. The only advantage I see in adding signals (but I'm not an expert of Django internals) is that it's pretty painless as it's five-lines patch, and it leaves all the other code unchanged. A possible short-term solution could be to apply the signals patch now, then when/if you implement mix-ins, add a custom one that uses signals so that people relying on them do not have to modify their code, but can simply pass the mix-in to the M2M field. They will then be able to gracefully migrate to a (possibly) cleaner solution writing their own mix-in. Ludo --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: per object permissions in admin using newforms-admin
Off list Yuri pointed me to a patch that by the look of it does exactly what I need: http://code.djangoproject.com/ticket/3987 Thanks Yuri! On 11 Sep, 16:02, "Yuri Baburov" <[EMAIL PROTECTED]> wrote: > 2007/9/11, andybak <[EMAIL PROTECTED]>: > > > Am I right in thinking that the current recommended approach to > > restricting admin access to certain objects (or rows) on a user by > > user basis is to use the admin hooks in newforms-admin? I've started > > using the querysethookto remove items from the changelist page. > > I have it done with querysethook. > I also have done workflow (with object statuses) and row-level > permissions for objects withnewforms-admin. > ...> I want users (who are linked to organisations) to only have rights to > > change their own items. Items are linked to organisation by a foreign > > key and thus are shown as a select list in admin. > > > I really want this select box to be replaced by a hidden field as the > > choice is predetermined by the logged in user but at the very least > > the foreign key lookup used to populate the select list needs ahook > > if I am to restrict users from changing items to a different > > organisation. > > Remove this field from a form or replace widget to one rendering nothing. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
