flatpages and 404
I just read over http://code.djangoproject.com/ticket/3335 and want to confirm a suspension that I would like to add to that 'thread' in an attempt to keep it closed: 404 processing happens, then the flat-pages code is given a chance to override it. This means that if the 404 processing fails, you get a stack dump where it failed. The fact that what is failing 'might' not be needed (in the case of a waiting flat-page entry) does not effect the fact that the code still crashed. I tend to agree that the DEBUG setting should not effect the flat-pages system the way it does, but I am comfortable with the resolution that it is an unfortunate side effect of the way flat-pages is implemented, and re-coding it to address the DEBUG issue isn't worth the effort. There was a note about improved docs, but the trac issue was also closed, which makes me think the doc patch isn't going to happen. I think http://www.djangoproject.com/documentation/flatpages/ needs: "Make sure you have a 404.template page before you set DEBUG=False or you will get a stack dump even when there is a valid flat-page waiting." This will address the "violates the principle of least surprise" and I have to admit, I too was surprised. Carl K --~--~-~--~~~---~--~~ 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: flatpages and 404
Sigh. In [7555] I added a warning to the flatpages docs to hopefully silence this issue once and for all. Note that I did this not because I feel it's necessary or appropriate, but because I'm just getting really, really, really tired of people complaining about this. Can we please let this one go now, finally? Please? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Any reason for Field subclasses calling super on get_db_prep_save?
I see that almost all Field subclasses which implements get_db_prep_save end calling Field.get_db_prep_save anyway. That's curious, because Field.get_db_prep_save is a no-op. Is it just some OOP style which we want to keep? -- Leo Soto M. http://blog.leosoto.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: Any reason for Field subclasses calling super on get_db_prep_save?
Today it may be empty, but tomorrow there can appear some useful code. So I think its better to follow that style. On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > I see that almost all Field subclasses which implements > get_db_prep_save end calling Field.get_db_prep_save anyway. That's > curious, because Field.get_db_prep_save is a no-op. > > Is it just some OOP style which we want to keep? > > -- > Leo Soto M.http://blog.leosoto.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: newforms-admin customisation hook suggestions
We had some discussions during PyCon in Chicago, the biggest issue we
have with the hooks is the amount of code needed to change the widgets
we talked with Joseph about something like widget-sets, a mapping prom
either field, or perhaps field type to widgets, that could be easily
defined - the simplest way to do that seems to be a dictionary
{ 'field_name': WidgetClass, ...}
it is a special case, true, but it covers 80% of cases when people
override the get_formfield_for_dbfield, which is ALWAYS messy...
On Wed, May 28, 2008 at 8:27 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> We (GCap, large commercial radio company in the UK) have been
> developing against the newforms-admin branch for a few months now, and
> based on that experience I have a number of suggestions for simple
> hooks that could be added to make it easier to customise.
>
> 1. Provide a custom template for a changelist / change form
>
> You should be able to specify a custom template for those pages in
> some way on the ModelAdmin object. At the moment select_template() is
> used to allow custom templates to be specified, but that isn't nearly
> flexible enough: it forces you to name your templates according to a
> certain naming scheme (e.g. admin/events/venue/change_form.html) but
> that means that you can't offer two admin interfaces with different
> templates for editing a specific thing, which is kind of the whole
> point of newforms admin allowing you to set up more than one admin
> site. It also forces you to keep your templates in an admin/ hierarchy
> which can be a bit limiting.
>
> There are two potential solutions to this. The first is to have a
> change_form_template option on the ModelAdmin:
>
> class EventAdmin(ModelAdmin):
>change_form_template = 'foo/bar/event_change_form.html'
>
> The other is to have the template provided by a method which can be
> over-ridden:
>
> class EventAdmin(ModelAdmin):
>def change_form_template(self, object=None):
>return select_template(['foo.html', 'bar.html'])
>
> Either look OK to me - the second is probably better as it lets you
> run a bit of logic to decide which template to use.
>
> Another benefit of this approach: it makes it easier to extend the
> default admin template without fear of running in to the dreaded
> template recursion problem.
>
> Custom templates for ModelAdmins is absolutely my number one request
> for newforms admin. It would make a huge number of customisations a
> great deal easier (we have a UED guy who keeps on coming up with
> genuinely good ideas for tweaks to our various admin screens).
>
> 2. Better hooks for custom form fields (esp. ForeignKey choices)
>
> Every time I write a formfield_for_dbfield method I want to strangle a
> kitten. I am not alone; this is pretty much the consensus among the
> developers I work with. There really, really needs to be a better way
> of doing per-form-field customisations.
>
> One extremely important example is being able to alter the choices in
> a ForeignKey or ManyToMany field, as discussed on this ticket:
>
> http://code.djangoproject.com/ticket/3987
>
> This is critically important because one of the big new features in
> newforms-admin is the ability to do row-level permissions, thanks to
> the extremely neat has_change_permission / has_change_permission /
> has_delete_permission hooks and the ability to over-ride the queryset
> for a changelist.
>
> Unfortunately this doesn't go quite far enough. If you're dealing with
> row level permissions ("user X can edit article Y") you also need to
> be able to restrict foreign key relationships. User X might only be
> allowed to assign an article to 4 out of the 30 categories on a site,
> for example.
>
> Ticket #3987 solves this in a reasonable way, but I'm not too keen on
> the suggested dynamic method name (dynamic_FIELDNAME_choices). I
> talked this over a bit with Stuart Langridge and we came up with the
> following:
>
> class BookAdmin(ModelAdmin):
>...
>def choices_for_author(self, request, book=None):
>user = request.user
>if not book:
># Creating a new book: return queryset for author choices
> that
># the current user is allowed to assign
>else:
># Editing an existing book; maybe do something a bit
> different?
>
> Using choices_for_FIELDNAME feels like it fits better with existing
> Django conventions (like clean_FIELDNAME in newforms).
>
> Then we thought, why not take this further? The most common things you
> do with formfield_for_dbfield are setting a custom widget and setting
> a custom formfield. So why not allow these:
>
>def widget_for_author(...):
>return CustomWidgetOfSomeSort()
>
>def formfield_for_title(...):
>return FormFieldOfSomeSort()
>
> But what if you want to reuse the same method for many different
> fields? We could provide fallback methods widget_for(self, dbfield),
> formfield_for(self, dbfield) and choices_for(self, dbfield) to co
Re: newforms-admin customisation hook suggestions
On May 29, 12:21 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> We had some discussions during PyCon in Chicago, the biggest issue we
> have with the hooks is the amount of code needed to change the widgets
>
> we talked with Joseph about something like widget-sets, a mapping prom
> either field, or perhaps field type to widgets, that could be easily
> defined - the simplest way to do that seems to be a dictionary
> { 'field_name': WidgetClass, ...}
I prefer methods over classes in a dictionary as using methods
provides a natural way to programatically decide on the widget based
on other factors. Generally speaking, the more information that's
available at the time of customisation (things like the request object
for example) the more flexible the API is.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Runtime initialisation of db_table from context
Hi Everyone, I've been doing some prototyping with django to see how good of a fit it will be for an upcoming project, and would like to run an idea past you guys. I'll try and explain my situation first, and then ask the question afterward. At a very high level, I have an application, which holds many organisations, and these organisations each contain many products. I may need to at times, partition the product data, so that some organisation products are stored in table 'a' and others are stored in table 'b'. However the Product as a model class is the same between both of these, and I won't know the names of these tables until runtime (they may be based on organisation names, which would be created by users). So as you might already have guessed, I would like to be able to use my "Product" model class across many tables. I would do this by changing the value of db_table. This however only works for saving an instance of Product (I can change the db_table value for that instance, prior to saving, and it will be committed to said table). I cannot however change the db_table property for a single thread, so as to fetch a Product from any arbitrary table name. I believe what would be needed is the ability to supply a context at runtime, from which db_table could be determined, i.e. Product.objects.all(ctx) where ctx.db_table is the name of the product table I wish to use That is a very quick and dirty example, however I hope I have still made sense and might be able to get some feedback from the developer community. Thanks! Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ERROR:cannot import name Post -- while using django signals
http://www.mercurytide.co.uk/whitepapers/django-signals/ according to the documents in above URL i am trying to implement signals in django. but getting the following error --cannot import name Post please help me out how to include this Post signal in the model -- the lines of code are as follows -- from django.contrib.auth.models import User from django.db import models from django.db.models import signals from django.dispatch import dispatcher from ravi_admin.admin.signals import send_entry_created_email class blog(models.Model): - dispatcher.connect(send_entry_created_email, signal=signals.post_save, sender=Entry) --- thnaks Ravindra --~--~-~--~~~---~--~~ 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: Multiple database support
On 22 mei, 18:28, "Ben Ford" <[EMAIL PROTECTED]> wrote: > Hi all, > > I've now re-applied Daryls patch (which was against qsrf) to a clone of > django trunk in a mercurial repo. It's available > athttp://hg.woe-beti.deandthere's a trac set up for it > athttp://trac.woe-beti.de. Feel free to make use of both of these. Although > I've disabled to ability to create tickets perhaps the wiki might be a good > place to discuss the API? Anyone can clone from the hg repo, give me a shout > if you would like push access and I'll sort it out. > > Cheers, > Ben > > -- > Regards, > Ben Ford > [EMAIL PROTECTED] > +447792598685 I have been adding some code to Ben's mercurial repo on [http://hg.woe- beti.de], see also [http://trac.woe-beti.de]. What has been realised (more or less): - connection and model registration - validation that related objects use the same connection - database_engine specific SQL generation (needs more checking) - some management commands accept connection parameter, others can generate output for multiple connections - syncdb can sync different connections - transaction management over connections - some tests (needs a lot more work) This means point 3 of the discussion at [http://trac.woe-beti.de/wiki/ Discuss] is somewhat working, but definitely needs a lot more testing. I do need some help with creating tests for all this though. I have not figured out yet how to create tests that check that the right SQL is being generated for the backend used. (Nor how to test the right database was touched by an action, this is quite obvious manually, but I do not know how to automate this.) I put some ideas on using multiple databases for copying (backup or migration) of objects (point 4 of the discussion note) in [http:// trac.woe-beti.de/wiki/APIModelDuplication]. Please comment, add, shoot etc. Any help will be much appreciated. Koen --~--~-~--~~~---~--~~ 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: ERROR:cannot import name Post -- while using django signals
the code in the signals.py is like -- - from django.core.mail import send_mass_mail from django.template import Context, loader from ravi_admin.admin.models import Post -- -- Forwarded message -- From: ravindra goyal <[EMAIL PROTECTED]> Date: Wed, May 28, 2008 at 12:37 PM Subject: ERROR:cannot import name Post -- while using django signals To: django-developers@googlegroups.com http://www.mercurytide.co.uk/whitepapers/django-signals/ according to the documents in above URL i am trying to implement signals in django. but getting the following error --cannot import name Post please help me out how to include this Post signal in the model -- the lines of code are as follows -- from django.contrib.auth.models import User from django.db import models from django.db.models import signals from django.dispatch import dispatcher from ravi_admin.admin.signals import send_entry_created_email class blog(models.Model): - dispatcher.connect(send_entry_created_email, signal=signals.post_save, sender=Entry) --- thnaks Ravindra --~--~-~--~~~---~--~~ 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: Google Summer of Code Markdown
another gigantic +1 On May 26, 8:51 am, rcs_comp <[EMAIL PROTECTED]> wrote: > On May 26, 6:27 am, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > > > Also not Django specific but support for Markdown Extra would be super- > > cool: > > >http://michelf.com/projects/php-markdown/extra/ > > Big +1! --~--~-~--~~~---~--~~ 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: Ability to specify a skeleton project
i would use it as well. i was actually thinking how on earth could i simplify the same thing i do for every single project (splitting settings.py to allow for revision control, splitting urls.py, etc.) On May 27, 8:30 am, "Valts Mazurs" <[EMAIL PROTECTED]> wrote: > Hi, > > This one sounds like a useful feature. I always run "django-admin.py > startproject blabla" and then replace/edit urls.py and settings.py to > introduce my own style. > > BR > Valts. > > On Tue, May 27, 2008 at 2:49 PM, David Reynolds <[EMAIL PROTECTED]> > wrote: > > > > > Hi, > > > We currently have a shell script that creates a skeleton project > > which sticks in a customised urls.py and settings.py along with some > > other bits and bobs. Now this script is a bit hacky and has proved > > fairly difficult to maintain as django has changed over the years. > > It occurred to me that it would be very nice if you could pass a an > > option to startproject to allow you to customise what skeleton is > > used. For example: > > > ./manage.py startproject --skel=/path/to/your/project/skeleton $ > > (thinkofagoodprojectname) > > > I was looking for feedback on whether this would be a good idea and > > whether it is something other people would use. Any thoughts? > > > Thanks, > > > David > > > -- > > David Reynolds > > [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 -~--~~~~--~~--~--~---
Re: {GSoC 2008}Django-Newcomments : A preview
Thanks a lot for the good work. A newbie here, and have a question on the comment model. Isn't it cleaner to look at the threaded comments in another way, e.g., if comment B is a reply to comment A, then the content_object of B is simply A instead of the original content object a comment is attached to? That way you can get rid of the 'parent', because 'content_object' is the 'parent'. You may calculate the 'level' by recursively looking at the content_object's content_type. If it's not a comment then you've reached the top of the thread. In this way, a non-threaded comment is just a threaded comment with maximum level 1, and the post_comment and reply_comment can be merged. Also a 'modify_date' may be useful for the abstract comment model. One of the benefits you might want to provide to the authenticated users is to modify their comments. Thanks, Zhiwu Xie Thejaswi Puthraya wrote: > Hello folks, > My exams got done in the first week of May. I was feeling quite bored > and so started working on the project. > > I completed a few items from the Todo list but need to complete the > documentation and write more tests. > > The code for my project is at > http://code.google.com/p/django-newcomments/ > and at > http://gitorious.org/projects/django-newcomments > > I also have put up the four demos in the source at: > > Demo-1: Using django-newcomments as a standalone app. > http://sandbox.thejaswi.info/example1/authors/ > > Demo-2: Using django-newcomments placing it in django.contrib.comments > (after removing the current django.contrib.comments) > http://sandbox.thejaswi.info/example2/books/ > > Demo-3: A simple threaded comments demo (inspired from Eric > Florenzano's project). > http://sandbox.thejaswi.info/example3/comics/ > > Demo-4: A custom comments demo > http://sandbox.thejaswi.info/example4/messages/ > > Current Problems faced: > * Abstract models don't allow custom managers. Tickets 7154 and 7252 > handle that (I am running trunk patched with ticket 7154). > * Abstract models don't allow the inheritance of the inner admin > class. After a discussion on IRC, I was assured that this was a small > issue that newforms-admin would cover after it supports model- > inheritance. Till then an abstract model designer cannot pass on a > neat admin UI to the user :( > > Please do let me know of any suggestions/criticisms and/or feedback. > > -- > Cheers > Thejaswi Puthraya > http://thejaswi.info/ > > > --~--~-~--~~~---~--~~ 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: On aggregates
>
> Providing a way to count different fields is a good idea, and the
> approach you've described looks good to me. I just wanted to make sure
> that the simplest case (count all instances) is trivial (i.e., doesn't
> require explicit naming of the PK field).
>
This is fixed in the latest revision. Now it is possible to do:
>>> explicit = list(Author.objects.annotate(Count('book__id')))
>>> implicit = list(Author.objects.annotate(Count('book')))
>>> explicit == implicit
True
>>> * Is a distinct option required as part of the Count operator? I would
>>> have thought the existing distinct() queryset modifier would be
>>> sufficient.
>>
>> distinct is optional. The problem with using the distinct() queryset
>> modifier is that it would affect the entire query.
> ...
> Kids.objects.annotate(Count('friends__toys'), Count('friens__toys',
> distinct=True))
>
>> while distinct would act on the select, or, even if we adapt it, it
>> would act inside all the Count objects.
>
> Ah - I hadn't considered COUNT(DISTINCT *). This seems like a
> reasonable to me. It also acts as a validation for choosing the
> function notation for aggregates - this wouldn't have been possible if
> we were using the __count= syntax.
>
True. And for custom aggregate functions the option of having multiple
parameters seems very useful.
I believe it would be quite clean to introduce subqueries in common
cases like this. Especially when dealing with aggregate since
aggregate is a terminal clause.
>>>
>>> If we need subqueries, I'd rather be explicit about it: e.g.,
>>>
>> Book.objects.filter(author__in=Author.objects.filter(...))
>>>
>> (strong statements to come... please correct me if im wrong)
>>
>> There are two possibilities in which I think subqueries might be
>> useful (regarding aggregation).
>
> Don't get me wrong - I can see that subqueries can be useful. I'm just
> hesitant to try and induce subqueries from a flat query syntax. If
> subqueries are required, my gut reaction is that we will have less
> headaches if we make the definition language able to express
> subqueries.
>
I think also that being explicit is more django-ish/pythonic but, as
you said
> That said - if there are very clear and obvious rules for when a
> subquery will get formed, this might be ok. More on this below.
>
...there might be some exceptions.
I think this is also far ahead. so Ill keep a note on it not to forget
it, but wont deal with it until the first version is ready, tested and
documented.
>> the way to express this in our syntax would be (intuitively and
>> regardless of the underlaying sql):
>> annotate(...).aggergate(...)
>>
>> This could result in a subquery or could be restricted in favour of
>> some more explicit syntax as you suggest.
>>
>> I possibility to make this explicit (though to me it seems ugly) would be:
>> Book.objects.aggregate(Avg(Book.objects.annotate(num_authors=Count('authors')))
>> )... maybe it would need also a way of specifying on which field to
>> aggregate.
>
> I agree that this approach isn't pretty.
>
> I think I have a slightly better idea of what you are proposing. If
> I'm understanding you correctly, you're working on the idea that:
>
> SELECT AVG(pages) FROM Book
>
> is essentially the same as
>
> SELECT AVG(pages) from (SELECT pages FROM Book)
>
> The second form is an inefficient - in practice, you would remove the
> subquery as an optimization - but it is a generic construction that
> lends itself to more complex inner queries, including those that have
> annotate() clauses:
>
> SELECT AVG(num_authors) from (SELECT id, name, COUNT(author.id) AS
> num_authors FROM Book INNER JOIN Author ...
>
> Given that aggregate() is a terminal clause, users aren't ever going
> to be affected by the existence of the subquery, so I suppose that
> this isn't so bad.
>
I agree. I'll probably bring the subject up again in a few weeks to
discuss a good syntax for subqueries and the possibility of doing it
implicity in annotate().aggregate() (which should be carefully
documented!)
> I still have a gut feeling that you should be able to compose this
> query without a subselect. However, I would need to sit down and look
> at the problem for a while to confirm that.
>
> After all that - I wouldn't get too hung up on these last cases. I
> posed them as intentionally difficult queries. While it would be nice
> to be able to handle the, getting the simple cases working (especially
> joins) is a much bigger priority. There will always be queries that
> can't be expressed using the ORM - the goal is to make the 80% of
> common queries trivial. The remaining 20% can always be serviced using
> raw SQL.
>
Good.
There is still the issue of the difference between
>>> Book.objects.all().filter(authors__name__contains='Norvig').annotate(num_authors=Count('authors__id')).filter(num_authors__gt=1)
and
>>> Book.objects.all().annotate(num_authors=Count('authors__id')).filter(authors__name__contains='Norvi
Re: newforms-admin FormSet API
On 2008-05-27 05:33:01 -0600, "Russell Keith-Magee" <[EMAIL PROTECTED]> said: > Is there any particular reason that you can't just add a Meta class to > this class definition, in the same way that a ModelForm works: > > class ArticleFormSet(FormSet) > class Meta: > form = ArticleForm > extra = 2 > can_delete = True > > def clean(self): > raise forms.ValidationError, u'An error occured.' > > I'm guessing InlineFormSet and ModelFormSet will need their own meta > class processing to handle their specific options, but there should be > a lot of common code between them. I made an attempt to normalize the API in 6241 [1]. That is where we decided that it was really complicating things. It may have been in my implementation itself. I am still not opposed to doing some sort of normalization, but at this point not sure how to go about simplifying the implementation. [1]: http://code.djangoproject.com/ticket/6241 -- Brian Rosner http://oebfare.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: newforms-admin FormSet API
> Should I be looking at any other documentation, or code, that you are > developing? Yes. What you have brought up is actually not the use case for formsets. However, you do bring up something that makes me want to clarify in the docs a bit more. When I say multiple forms per page, that really doesn't mean having fields from N models that are grouped together in some fashion and presented in different locations on the page to make it more user friendly. What it really means is having multiple Form/ModelForm objects that are equivalent in fields and bound to some list dataset. Just like the edit_inline functionality found in the admin. All your other issues deal directly with newforms yourself. I would give the newforms and modelforms documentation again. newforms: http://www.djangoproject.com/documentation/newforms/ modelforms: http://www.djangoproject.com/documentation/modelforms/ -- Brian Rosner http://oebfare.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: Which editor for Django code ??
I use Textmate (with the Django bundle) and soft-tabs. Sometimes If I paste code from the web there are indentation problems. Here's what I use for quick clean-up: * search for [tab] and replace with [4 spaces] (using soft-tabs) I recorded a macro which does "select all" and then performs this search and replace. Then I tied it to a hot-key. So if pasted code has a problem, I just hit cmd-f3 and the problem is solved. Or In some cases I use: * "Cleanup whitespace" from the Python bundle or * "Show Invisibles" from the "View" menu to help spot the inconsistency visually. Hope this helps, Daniel On May 14, 9:31 am, "narendra.tumkur" <[EMAIL PROTECTED]> wrote: > Hi guys, > Trying to edit django code and keep running into indentation problems. > Have tried XCode, Textmate and JEdit on Mac OS X. > > What do you guys use? > > Cheers > Narendra --~--~-~--~~~---~--~~ 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: Which editor for Django code ??
Seems you've done a bit of duplicate work. If you're in Textmate, try going to Text>Convert>Spaces to Tabs (or) Tabs to Spaces Should do what your script does, I think. -justin On Wed, May 28, 2008 at 12:46 PM, Daniel Bushman <[EMAIL PROTECTED]> wrote: > > I use Textmate (with the Django bundle) and soft-tabs. Sometimes If I > paste code from the web there are indentation problems. Here's what > I use for quick clean-up: > > * search for [tab] and replace with [4 spaces] (using soft-tabs) > > I recorded a macro which does "select all" and then performs this > search and replace. Then I tied it to a hot-key. So if pasted code > has a problem, I just hit cmd-f3 and the problem is solved. > > Or In some cases I use: > > * "Cleanup whitespace" from the Python bundle > or > * "Show Invisibles" from the "View" menu to help spot the > inconsistency visually. > > Hope this helps, > Daniel > > On May 14, 9:31 am, "narendra.tumkur" <[EMAIL PROTECTED]> > wrote: > > Hi guys, > > Trying to edit django code and keep running into indentation problems. > > Have tried XCode, Textmate and JEdit on Mac OS X. > > > > What do you guys use? > > > > Cheers > > Narendra > > > -- Justin Lilly Web Developer/Designer http://justinlilly.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: ERROR:cannot import name Post -- while using django signals
Usage questions belong on django-users - this list is for the development of django itself. -- 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 -~--~~~~--~~--~--~---
newforms-admin customisation hook suggestions
We (GCap, large commercial radio company in the UK) have been
developing against the newforms-admin branch for a few months now, and
based on that experience I have a number of suggestions for simple
hooks that could be added to make it easier to customise.
1. Provide a custom template for a changelist / change form
You should be able to specify a custom template for those pages in
some way on the ModelAdmin object. At the moment select_template() is
used to allow custom templates to be specified, but that isn't nearly
flexible enough: it forces you to name your templates according to a
certain naming scheme (e.g. admin/events/venue/change_form.html) but
that means that you can't offer two admin interfaces with different
templates for editing a specific thing, which is kind of the whole
point of newforms admin allowing you to set up more than one admin
site. It also forces you to keep your templates in an admin/ hierarchy
which can be a bit limiting.
There are two potential solutions to this. The first is to have a
change_form_template option on the ModelAdmin:
class EventAdmin(ModelAdmin):
change_form_template = 'foo/bar/event_change_form.html'
The other is to have the template provided by a method which can be
over-ridden:
class EventAdmin(ModelAdmin):
def change_form_template(self, object=None):
return select_template(['foo.html', 'bar.html'])
Either look OK to me - the second is probably better as it lets you
run a bit of logic to decide which template to use.
Another benefit of this approach: it makes it easier to extend the
default admin template without fear of running in to the dreaded
template recursion problem.
Custom templates for ModelAdmins is absolutely my number one request
for newforms admin. It would make a huge number of customisations a
great deal easier (we have a UED guy who keeps on coming up with
genuinely good ideas for tweaks to our various admin screens).
2. Better hooks for custom form fields (esp. ForeignKey choices)
Every time I write a formfield_for_dbfield method I want to strangle a
kitten. I am not alone; this is pretty much the consensus among the
developers I work with. There really, really needs to be a better way
of doing per-form-field customisations.
One extremely important example is being able to alter the choices in
a ForeignKey or ManyToMany field, as discussed on this ticket:
http://code.djangoproject.com/ticket/3987
This is critically important because one of the big new features in
newforms-admin is the ability to do row-level permissions, thanks to
the extremely neat has_change_permission / has_change_permission /
has_delete_permission hooks and the ability to over-ride the queryset
for a changelist.
Unfortunately this doesn't go quite far enough. If you're dealing with
row level permissions ("user X can edit article Y") you also need to
be able to restrict foreign key relationships. User X might only be
allowed to assign an article to 4 out of the 30 categories on a site,
for example.
Ticket #3987 solves this in a reasonable way, but I'm not too keen on
the suggested dynamic method name (dynamic_FIELDNAME_choices). I
talked this over a bit with Stuart Langridge and we came up with the
following:
class BookAdmin(ModelAdmin):
...
def choices_for_author(self, request, book=None):
user = request.user
if not book:
# Creating a new book: return queryset for author choices
that
# the current user is allowed to assign
else:
# Editing an existing book; maybe do something a bit
different?
Using choices_for_FIELDNAME feels like it fits better with existing
Django conventions (like clean_FIELDNAME in newforms).
Then we thought, why not take this further? The most common things you
do with formfield_for_dbfield are setting a custom widget and setting
a custom formfield. So why not allow these:
def widget_for_author(...):
return CustomWidgetOfSomeSort()
def formfield_for_title(...):
return FormFieldOfSomeSort()
But what if you want to reuse the same method for many different
fields? We could provide fallback methods widget_for(self, dbfield),
formfield_for(self, dbfield) and choices_for(self, dbfield) to cover
that.
Yes, this means adding a lot of potential methods to ModelAdmin
(though note that since they are dynamically looked up we don't have
to add any real new methods to the actual class itself). I think
that's fine - it makes for an API that is clean, powerful and
extremely easy to understand.
I realise that some of the above could be mocked up just by writing a
custom formfield_for_dbfield method without patching newforms-admin at
all. I plan to do that as a proof of concept.
3. Make it easier to include custom CSS and JavaScript
By far the easiest way to tweak the admin is with a bit of unobtrusive
CSS and JavaScript. We're using jQuery a lot for this (to great
effect; for example, we've got a really nice drag-and-drop reordering
i
