Re: Ability to change dismissRelatedLookupPopup on my own callback function
> It might be worth considering if there are any methods for passing a > callback function that are better than GET parameters—though I can't > think of any off the top of my head. > I can't provide better solution too. I look at the django.contrib.admin source. This can be applied only if 'pop' argument exists in GET parameters for changelist and '_popup' argument exists in GET parameters for adding new item. The changes will be affect to methods are listed below: - django.contrib.admin.options.ModelAdmin.response_add - django.contrib.admin.templatetags.admin_list.items_for_result - django.contrib.admin.views.main.ChangeList.__init__ Cheers! -- Alex Kamedov skype: kamedovwww: kamedov.ru -- 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: More Class Based Views
On Wed, Jun 8, 2011 at 12:46 PM, Iván Raskovsky wrote: > Well.. I wasn't sure when to send this email, mostly cause I haven't > had time to properly document everything, but Russ' talk Wither > Django[0] seems to have done it. > > One of the points he mentions in what he'd like in 1.4 is "More Class > Based Views". I've started working sporadically in an external app[1] > before 1.3 was released. > > I've implemented CBV for formsets, modelformsets and inline > formsets[2], and with some more work in them I think they could be the > base of something that could get into core. I've based my work in both > the actual generic CBV and how the admin treats inlines. Should open a > ticket for this? > > I would appreciate help with documentation; English and documentation > are not my forte. > > Apart from this we could get some other Mixins and CBV into core. Ideas? > > Another thing I think is reaaally important is better CBV > documentation. Most people I've talked about CBV agrees that the > documentation is not enough and that one has to dig into the code to > figure out how everything works and what to override. Russ has just > said it's very improvable. Django CBVs have been called code ravioli, > and it doesn't help that the documentation isn't that good. > > Some ideas might be making a parallel tutorial using CBV, or add a > step where you can rewrite everything as CBV. Another thing I'd like > to see are examples where we override each CBV and different parts of > each, with real life examples. I can help here. Which do you think > would be the best approach? > > I'll be online tomorrow at #django-sprint since 8am GMT-3 more or less. > > I hope more people is interested in this so that we can work together. > > Regards, > Iván > > [0] http://www.djangocon.eu/talks/26/ > [1] https://github.com/rasca/django-enhanced-cbv > [2] > https://github.com/rasca/django-enhanced-cbv/blob/master/enhanced_cbv/views/edit.py > I've just filled ticket #16256 [0] and attached the code for the formsets derived views. If anyone can review it, I can improve the code later. Thanks! Iván [0] https://code.djangoproject.com/ticket/16256 -- 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: Logging configuration and handle_uncaught_exception
On Jun 10, 2:05 pm, Matt Bennett wrote: > Is there a reason the call to logger.error can't come before we return > the technical_500_response when DEBUG=True? It seems to me that the > debug level should be checked in each individual handler, rather than > determining whether the error is passed to the logger at all. Aren't these two separate things? It makes sense to have the logging of errors occur in all code paths, but that isn't connected with levels on handlers. The first requires the logging call to be added to the code, whereas levels on handlers can be configured to be as verbose (or not) as you like, independently of logging calls in the code. Regards, Vinay Sajip -- 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.
Error with new version of psycopg2 [ticket 16250]
When i use the version 2.4.1 of psycopgs testing works normal, but with 2.4.2 i got this error: https://code.djangoproject.com/ticket/16250 -- 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: Undocumented feature for INSTALLED_APPS settings
On 13 juin 2011, at 18:07, Jannis Leidel wrote: > On 13.06.2011, at 17:19, Carl Meyer wrote: >> I agree with all of this. I would be in favor of simply removing the >> wildcard feature with a note in the release notes, unless someone pops >> up to argue that it's more widely-used than we think and it should be >> deprecated instead, in which case I think a normal deprecation path is a >> fine alternative. > > +1 on the strategy. I have created a ticket and a patch to implement Carl's recommendation: https://code.djangoproject.com/ticket/16247 Could someone review it? Best regards, -- Aymeric Augustin. -- 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: Undocumented feature for INSTALLED_APPS settings
On 13.06.2011, at 17:19, Carl Meyer wrote: > On 06/12/2011 03:35 PM, Aymeric Augustin wrote: >> I checked the SVN history. This "feature" was never documented, even >> before the reorganization at r8506. It appears in >> django/conf/__init__.py when magic-removal is merged (r2809). >> >> We just discussed it on IRC, and the consensus is that it dates back >> to before Django was open-sourced. It was probably only used at World >> Online. >> >> In my opinion, it's an anti-feature: 1 - It's un-pythonic: in >> essence, it's equivalent to an filesystem-based implementation of >> "from import *", which was not rejected in Python for a >> good reason [1] 2 - like "from import *", it's not >> explicit, 3 - you don't add apps to your settings file every day, so >> there's little to gain. >> >> I think it should be deprecated; since it was never documented, we >> could even remove it outright. > > I agree with all of this. I would be in favor of simply removing the > wildcard feature with a note in the release notes, unless someone pops > up to argue that it's more widely-used than we think and it should be > deprecated instead, in which case I think a normal deprecation path is a > fine alternative. +1 on the strategy. Jannis -- 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: Undocumented feature for INSTALLED_APPS settings
On 06/12/2011 03:35 PM, Aymeric Augustin wrote: > I checked the SVN history. This "feature" was never documented, even > before the reorganization at r8506. It appears in > django/conf/__init__.py when magic-removal is merged (r2809). > > We just discussed it on IRC, and the consensus is that it dates back > to before Django was open-sourced. It was probably only used at World > Online. > > In my opinion, it's an anti-feature: 1 - It's un-pythonic: in > essence, it's equivalent to an filesystem-based implementation of > "from import *", which was not rejected in Python for a > good reason [1] 2 - like "from import *", it's not > explicit, 3 - you don't add apps to your settings file every day, so > there's little to gain. > > I think it should be deprecated; since it was never documented, we > could even remove it outright. I agree with all of this. I would be in favor of simply removing the wildcard feature with a note in the release notes, unless someone pops up to argue that it's more widely-used than we think and it should be deprecated instead, in which case I think a normal deprecation path is a fine alternative. Carl -- 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: Ability to change dismissRelatedLookupPopup on my own callback function
I think this is a great idea! I would certainly benefit from it. It might be worth considering if there are any methods for passing a callback function that are better than GET parameters—though I can't think of any off the top of my head. H. On Jun 13, 12:16 am, Alex Kamedov wrote: > Hi all! > > I make integration with warehouse system and want to reuse existing > functionality in django.contrib.admin to manage links between this system > and catalog on site. > I can't get access to warehouse system database, I have only export file. I > write some views to represent its items in django admin. And now I need > something like related field in django admin forms, but has some filters > applied to changelist and has some other user interface. > > I think, the best solution for this case is put some links with > showRelatedObjectLookupPopup javascript function on admin changelist, but > after user choose the object, my own javascript function must > be called instead of dismissRelatedLookupPopup javascript function. > > Execution of dismissRelatedLookupPopup is hard coded in python code now. The > easiest way to implement use case described higher is adding new GET > argument "_callback" to changelist view. > > What are you think about this? If this solution was accepted I can write > patch and tests for it. > > Cheers! > -- > Alex Kamedov > skype: kamedov www: kamedov.ru -- 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.
Customizable serialization. (Finally?)
Hi all,
Over the coding sprints at djangocon.eu I started working on a proposal
for customizable serialization. [1]
I've talked over the API and implementation with Russ, and I think we're
broadly happy with it all,
so I'd like to open it up to wider discussion.
What I have right now looks something like this:
1) Serialization is a two stage process - firstly serializing into native
datatypes, then rendering into json/xml/whatever.
2) Serialization behavior is specified by inheriting from a Serializer class
and setting various attributes such as 'fields', 'depth' etc... on an inner
'Meta' class.
3) Serialization of a given field on a model can be overridden by specifying
a method on the Serialization class.
4) Behavior can also be refined by overriding various public methods on
the Serializer class, if required.
5) Multiple Serialization classes can be composed together, to provide for
more complex behavior.
Here's an example of the proposed API, that replicates the existing json
serialization behavior, without any of the implicit assumptions about
serialization structure that are currently made:
class PKOnlySerializer(Serializer):
"""
Serializes models into their pk representation.
"""
def serialize_model(self, instance):
return instance.pk
class FieldsSerializer(Serializer):
"""
Serializes only the fields on a model.
"""
class Meta:
exclude = ('id', 'pk')
related_serializer = PKOnlySerializer
class DjangoSerializer(Serializer):
"""
Serializes into the existing django style.
"""
class Meta:
fields = ('pk', 'model', 'fields')
def model(self, instance):
return unicode(instance._meta)
def fields(self, instance):
return FieldsSerializer().serialize(instance)
Which can be used like this:
data = DjangoSerializer().serialize(queryset)
ret = json.dumps(data, cls=DateTimeAwareJSONEncoder, indent=4,
sort_keys=False)
The code as it stands is available on github [2].
You'll want to look at impl.py [3] for the implementation and views.py [4]
for example API usage.
The serializer currently supports depth-limited and recursion-limited
output, and I'm right now I'm looking to work on finalizing the xml related
issues,
adding some slightly more concise ways of being able to describe nested
models [Russ: I think this'll be closer to what you were looking for], and
then
trying to refactor Django to use the new serialization code, and see what
test breakage I come up against.
Would def welcome any constructive criticism of the API or implementation.
Also if anyone wants to help in contributing in order to get this (long
outstanding) feature into Django, that would be very much appreciated.
(I suspect there might be quite a lot to do once I look at merging into
Django!)
It's not totally impossible that we might be able to get this feature in for
1.4, which'd be pretty cool,
and there's also a bunch of serialization related tickets that we might be
able to close off in the process. [5]
Feedback?
t.
[1]
https://code.djangoproject.com/wiki/SummerOfCode2011#Customizableserialization
[2] https://github.com/tomchristie/scratch
[3] https://github.com/tomchristie/scratch/blob/master/myapp/impl.py
[4] https://github.com/tomchristie/scratch/blob/master/myapp/views.py
[5]
https://code.djangoproject.com/query?status=assigned&status=new&status=reopened&component=Core+(Serialization)&order=priority
--
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/-/ZIVyqCS9JZ0J.
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.
