Feedback: Syndication feed views
Hi all, I originally had great plans for refactoring the syndication contrib app, but a lack of time and the thorny issue of backwards compatibility has forced me to stick to the one big feature: making feeds class-based views. http://github.com/bfirsh/syndication-view/ The readme should be self explanatory. In short, instances of Feed subclasses (now in syndication.views rather syndication.feeds) can be used as views. The feed API is almost identical, except that get_object(), much like a view, takes the request and the URL arguments. More comprehensive tests and a modification of Django's documentation is on its way. This currently fixes tickets #6188, #6304, #6969, #8758, #8989 and #11069. I plan to fix the trivial tickets #6618, #7039, #7936, #10334, #11939 and #11973 before it's ready for committing. Ben -- 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: Feedback: Syndication feed views
I've made a few more changes, added many more tests and written documentation. This now fixes #6188, #6304, #6618, #6969, #8758, #8989, #10334, #11069 and #11973. Any final feedback would be appreciated. I'll put it together as a patch and put it in a ticket as soon as possible. Thanks, Ben On 28 Nov 2009, at 15:43, Ben Firshman wrote: > Hi all, > > I originally had great plans for refactoring the syndication contrib > app, but a lack of time and the thorny issue of backwards > compatibility has forced me to stick to the one big feature: making > feeds class-based views. > > http://github.com/bfirsh/syndication-view/ > > The readme should be self explanatory. In short, instances of Feed > subclasses (now in syndication.views rather syndication.feeds) can > be used as views. The feed API is almost identical, except that > get_object(), much like a view, takes the request and the URL > arguments. > > More comprehensive tests and a modification of Django's > documentation is on its way. > > This currently fixes tickets #6188, #6304, #6969, #8758, #8989 and > #11069. I plan to fix the trivial tickets #6618, #7039, #7936, > #10334, #11939 and #11973 before it's ready for committing. > > Ben > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > . > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Feedback: Syndication feed views
Patch and ticket done. Any comments? http://code.djangoproject.com/ticket/12403 Thanks, Ben On 17 Dec 2009, at 10:06, Ben Firshman wrote: > I've made a few more changes, added many more tests and written > documentation. This now fixes #6188, #6304, #6618, #6969, #8758, > #8989, #10334, #11069 and #11973. > > Any final feedback would be appreciated. I'll put it together as a > patch and put it in a ticket as soon as possible. > > Thanks, > > Ben > > On 28 Nov 2009, at 15:43, Ben Firshman wrote: > >> Hi all, >> >> I originally had great plans for refactoring the syndication contrib >> app, but a lack of time and the thorny issue of backwards >> compatibility has forced me to stick to the one big feature: making >> feeds class-based views. >> >> http://github.com/bfirsh/syndication-view/ >> >> The readme should be self explanatory. In short, instances of Feed >> subclasses (now in syndication.views rather syndication.feeds) can >> be used as views. The feed API is almost identical, except that >> get_object(), much like a view, takes the request and the URL >> arguments. >> >> More comprehensive tests and a modification of Django's >> documentation is on its way. >> >> This currently fixes tickets #6188, #6304, #6969, #8758, #8989 and >> #11069. I plan to fix the trivial tickets #6618, #7039, #7936, >> #10334, #11939 and #11973 before it's ready for committing. >> >> Ben >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com >> . >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en >> . >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-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. > > -- 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: Feedback: Syndication feed views
Oops, looks like I used the wrong git diff command and it didn't include any new files. I'll have a stab at the depreciation warnings too. Ben On 20 Dec 2009, at 02:49, Jacob Kaplan-Moss wrote: > On Sat, Dec 19, 2009 at 8:33 AM, Jacob Kaplan-Moss wrote: >> Code-wise, though, everything looks fine. Don't worry too much about >> getting to all the formal stuff: I'll probably be committing this >> today. > > Or not. There's a failing test in your patch:: > > == > FAIL: test_template_feed > (regressiontests.syndication.tests.SyndicationFeedTest) > -- > Traceback (most recent call last): > File > "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", > line 247, in test_template_feed >'link': 'http://example.com/blog/1/', > File > "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", > line 25, in assertChildNodeContent >elem.getElementsByTagName(k)[0].firstChild.wholeText, v) > AssertionError: u'Overridden description: My first entry' != > 'Description in your templates: My first entry' > > -- > > ... and I've not yet been able to figure out what's going on. Looks > like I won't have a chance to check it in before I leave for vacation > tomorrow. > > However, I'm +1 on the way you've done this, and would very much like > to see it get in. So any other committers should feel free to commit > this assuming Ben can track down and fix the bug. > > Jacob > > [Failing that, I'll probably stretch the definition of "minor feature" > a bit and plan to commit this for the beta instead...] > > -- > > 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. > > -- 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: Feedback: Syndication feed views
Okay, I've updated the ticket with a new patch: http://code.djangoproject.com/ticket/12403 I wasn't sure on the extent of the depreciation warnings required, but hopefully that's the sort of thing needed. Thanks, Ben On 20 Dec 2009, at 12:15, Ben Firshman wrote: > Oops, looks like I used the wrong git diff command and it didn't include any > new files. I'll have a stab at the depreciation warnings too. > > Ben > > On 20 Dec 2009, at 02:49, Jacob Kaplan-Moss wrote: > >> On Sat, Dec 19, 2009 at 8:33 AM, Jacob Kaplan-Moss >> wrote: >>> Code-wise, though, everything looks fine. Don't worry too much about >>> getting to all the formal stuff: I'll probably be committing this >>> today. >> >> Or not. There's a failing test in your patch:: >> >> == >> FAIL: test_template_feed >> (regressiontests.syndication.tests.SyndicationFeedTest) >> -- >> Traceback (most recent call last): >> File >> "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", >> line 247, in test_template_feed >> 'link': 'http://example.com/blog/1/', >> File >> "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", >> line 25, in assertChildNodeContent >> elem.getElementsByTagName(k)[0].firstChild.wholeText, v) >> AssertionError: u'Overridden description: My first entry' != >> 'Description in your templates: My first entry' >> >> -- >> >> ... and I've not yet been able to figure out what's going on. Looks >> like I won't have a chance to check it in before I leave for vacation >> tomorrow. >> >> However, I'm +1 on the way you've done this, and would very much like >> to see it get in. So any other committers should feel free to commit >> this assuming Ben can track down and fix the bug. >> >> Jacob >> >> [Failing that, I'll probably stretch the definition of "minor feature" >> a bit and plan to commit this for the beta instead...] >> >> -- >> >> 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. >> >> > > -- > > 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. > > -- 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: Feedback: Syndication feed views
On 21 Dec 2009, at 12:29, Luke Plant wrote: > On Sunday 20 December 2009 13:04:00 Ben Firshman wrote: >> Okay, I've updated the ticket with a new patch: >> >> http://code.djangoproject.com/ticket/12403 >> >> I wasn't sure on the extent of the depreciation warnings required, >> but hopefully that's the sort of thing needed. >> >> Thanks, >> >> Ben > > Some comments: > > * depreciated != deprecated. You mean the latter. There are various > instances of the former in comments and the names of test classes. Whoops, you're absolutely right. > > * Some docs need adding to the 1.2 release notes. Righto. > > * What is going to happen to feeds.Feed? Is it deprecated or not? > (there is no PendingDeprecationWarning AFAICS). > I for one have a lot of code that uses feeds.Feed directly, > bypassing the 'high level' framework that provided the view > function. I wasn't sure whether to add a warning to that, since it is always used through the feed() view. Though to be clear, I've added one. > If it is deprecated, what is the migration path? It really > would need to be specified in painstaking detail. I've documented it in some detail in the release notes. Is this painstaking enough? New patch is attached to the ticket. Thanks for the feedback, Ben -- 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: Feedback: Syndication feed views
On 21 Dec 2009, at 20:06, Luke Plant wrote: >> I've documented it in some detail in the release notes. Is this >> painstaking enough? > > Unless I'm missing something, it's not nearly there (but some of this > may be the 'formal stuff' that Jacob doesn't mind being missing for > now). > > First, views.Feed.get_object() takes different arguments to > feeds.Feed.get_object(). This is pretty confusing, and really needs > to be *much* clearer in the documentation (not just the release > notes). The same goes for the get_feed() method. You're right. I've now given it a little versionchanged directive in the main documentation, but perhaps this needs to be clearer. Note that get_feed() isn't documented at all, but all the same, I've made it clear it has changed in the release notes. > > The release notes imply that I can just switch from subclassing > feeds.Feed to view.Feed and change get_object(), and it will all work. > I can't see how that is possible: > > - I might have code that calls the constructor of feeds.Feed (or a > subclass) directly. But views.Feed has a different signature > altogether, and feeds.Feed.__init__() does a bit of work that my own > code is going to have to do once feeds.Feed disappears. Obviously > that code is doing something that will have to be done differently > with views.Feed. But how exactly? > > - I might have code that calls the get_feed() method of feeds.Feed > (or a subclass) directly. That method does extra work compared to > views.Feed.get_feed(). When feeds.Feed goes away, what does my code > need to be changed to? > > What I'm looking for is *step by step* instructions on how to update > my code, and a list of *all* the differences between views.Feed and > feeds.Feed, since the former is supposed to be the replacement for the > latter. I shouldn't have to look at *any* of the code or previous > documentation to work out what has changed. *All* the hard work > should have been done for me. This is about maintenance programmers, > who have been given a promise of backwards compatibility, who just > want their application to carry on working. I understand. I've added additional details in the release notes, but do we need step by step instructions on how to upgrade undocumented APIs? As far as the documented API is concerned, very little has changed. Under the hood though, Feed classes have changed significantly. It would require reams of documentation to take into account all the different ways people might be hacking with Feed classes. > > I'm insisting on this, because until we see it, it's very difficult to > work out how "backwards compatible" this really is, and whether we > should deprecate feeds.Feed at all. Jacob was happy for this to go in > without the formal stuff of documenting all this, so I guess we can > punt the decision about whether to deprecate feeds.Feed or not, but we > do need those docs at some point so we can see the implications of > deprecating feeds.Feed. I've gone through my changes and documented exactly what has changed as far as the user is concerned. The old API should be completely backwards compatible; the new Feed view certainly isn't. > > So for now, maybe just update the release notes so they don't say that > the new LatestEntries class is identical to before, or a caveat like > "if you are only using the high level feed framework (the feed() > view)" or something. > I've gone a little further than that in the patch I've just put on the ticket (1), but this probably needs documenting in more detail. Thanks, Ben (1) http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff (Why aren't my diffs showing? Are they too large for trac?) -- 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: Feedback: Syndication feed views
Is there any more documentation that I should write before the feature freeze tomorrow? Thanks, Ben On 22 Dec 2009, at 00:39, Ben Firshman wrote: > > On 21 Dec 2009, at 20:06, Luke Plant wrote: >>> I've documented it in some detail in the release notes. Is this >>> painstaking enough? >> >> Unless I'm missing something, it's not nearly there (but some of this >> may be the 'formal stuff' that Jacob doesn't mind being missing for >> now). >> >> First, views.Feed.get_object() takes different arguments to >> feeds.Feed.get_object(). This is pretty confusing, and really needs >> to be *much* clearer in the documentation (not just the release >> notes). The same goes for the get_feed() method. > > You're right. I've now given it a little versionchanged directive in > the main documentation, but perhaps this needs to be clearer. Note > that get_feed() isn't documented at all, but all the same, I've made > it clear it has changed in the release notes. > >> >> The release notes imply that I can just switch from subclassing >> feeds.Feed to view.Feed and change get_object(), and it will all >> work. >> I can't see how that is possible: >> >> - I might have code that calls the constructor of feeds.Feed (or a >> subclass) directly. But views.Feed has a different signature >> altogether, and feeds.Feed.__init__() does a bit of work that my own >> code is going to have to do once feeds.Feed disappears. Obviously >> that code is doing something that will have to be done differently >> with views.Feed. But how exactly? >> >> - I might have code that calls the get_feed() method of feeds.Feed >> (or a subclass) directly. That method does extra work compared to >> views.Feed.get_feed(). When feeds.Feed goes away, what does my code >> need to be changed to? >> >> What I'm looking for is *step by step* instructions on how to update >> my code, and a list of *all* the differences between views.Feed and >> feeds.Feed, since the former is supposed to be the replacement for >> the >> latter. I shouldn't have to look at *any* of the code or previous >> documentation to work out what has changed. *All* the hard work >> should have been done for me. This is about maintenance programmers, >> who have been given a promise of backwards compatibility, who just >> want their application to carry on working. > > I understand. I've added additional details in the release notes, > but do we need step by step instructions on how to upgrade > undocumented APIs? As far as the documented API is concerned, very > little has changed. Under the hood though, Feed classes have changed > significantly. It would require reams of documentation to take into > account all the different ways people might be hacking with Feed > classes. > >> >> I'm insisting on this, because until we see it, it's very difficult >> to >> work out how "backwards compatible" this really is, and whether we >> should deprecate feeds.Feed at all. Jacob was happy for this to go >> in >> without the formal stuff of documenting all this, so I guess we can >> punt the decision about whether to deprecate feeds.Feed or not, but >> we >> do need those docs at some point so we can see the implications of >> deprecating feeds.Feed. > > I've gone through my changes and documented exactly what has changed > as far as the user is concerned. The old API should be completely > backwards compatible; the new Feed view certainly isn't. > >> >> So for now, maybe just update the release notes so they don't say >> that >> the new LatestEntries class is identical to before, or a caveat like >> "if you are only using the high level feed framework (the feed() >> view)" or something. >> > > I've gone a little further than that in the patch I've just put on > the ticket (1), but this probably needs documenting in more detail. > > Thanks, > > Ben > > (1) > http://code.djangoproject.com/attachment/ticket/12403/syndication-views-4.diff > > (Why aren't my diffs showing? Are they too large for trac?) > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > . > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: idea for using RequestContext by default
On 5 Jan 2010, at 15:00, Jacob Kaplan-Moss wrote: > On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee > wrote: >> I haven't taken the temperature of anyone else in the core, but you >> can take it as read that Simon and myself are both +1. The sprint >> this >> weekend would be a great opportunity to advocate for inclusion of >> this. With a few tests and documentation, Simon's patch could easily >> be made trunk-ready. > > I'm also +1 on something like ``TemplateResponse``, and especially > ``django.shortcuts.render(request, template, context)``. I ran across a really frustrating problem with TemplateResponse. TemplateResponses typically get baked by a response middleware because that's the first place the content is accessed. However, if there are any template errors, you don't see a sensible traceback because pretty debug pages aren't shown for exceptions raised in middleware. Is there any reason why exceptions in middleware aren't handled? Ben -- 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: Feedback: Syndication feed views
Is it too late to sneak this in in as a minor feature? I have some time now, so I can write up some more documentation if it's needed. Ben On 4 Jan 2010, at 13:07, Ben Firshman wrote: > Is there any more documentation that I should write before the feature > freeze tomorrow? > > Thanks, > > Ben > > On 22 Dec 2009, at 00:39, Ben Firshman wrote: > >> >> On 21 Dec 2009, at 20:06, Luke Plant wrote: >>>> I've documented it in some detail in the release notes. Is this >>>> painstaking enough? >>> >>> Unless I'm missing something, it's not nearly there (but some of this >>> may be the 'formal stuff' that Jacob doesn't mind being missing for >>> now). >>> >>> First, views.Feed.get_object() takes different arguments to >>> feeds.Feed.get_object(). This is pretty confusing, and really needs >>> to be *much* clearer in the documentation (not just the release >>> notes). The same goes for the get_feed() method. >> >> You're right. I've now given it a little versionchanged directive in >> the main documentation, but perhaps this needs to be clearer. Note >> that get_feed() isn't documented at all, but all the same, I've made >> it clear it has changed in the release notes. >> >>> >>> The release notes imply that I can just switch from subclassing >>> feeds.Feed to view.Feed and change get_object(), and it will all >>> work. >>> I can't see how that is possible: >>> >>> - I might have code that calls the constructor of feeds.Feed (or a >>> subclass) directly. But views.Feed has a different signature >>> altogether, and feeds.Feed.__init__() does a bit of work that my own >>> code is going to have to do once feeds.Feed disappears. Obviously >>> that code is doing something that will have to be done differently >>> with views.Feed. But how exactly? >>> >>> - I might have code that calls the get_feed() method of feeds.Feed >>> (or a subclass) directly. That method does extra work compared to >>> views.Feed.get_feed(). When feeds.Feed goes away, what does my code >>> need to be changed to? >>> >>> What I'm looking for is *step by step* instructions on how to update >>> my code, and a list of *all* the differences between views.Feed and >>> feeds.Feed, since the former is supposed to be the replacement for >>> the >>> latter. I shouldn't have to look at *any* of the code or previous >>> documentation to work out what has changed. *All* the hard work >>> should have been done for me. This is about maintenance programmers, >>> who have been given a promise of backwards compatibility, who just >>> want their application to carry on working. >> >> I understand. I've added additional details in the release notes, >> but do we need step by step instructions on how to upgrade >> undocumented APIs? As far as the documented API is concerned, very >> little has changed. Under the hood though, Feed classes have changed >> significantly. It would require reams of documentation to take into >> account all the different ways people might be hacking with Feed >> classes. >> >>> >>> I'm insisting on this, because until we see it, it's very difficult >>> to >>> work out how "backwards compatible" this really is, and whether we >>> should deprecate feeds.Feed at all. Jacob was happy for this to go >>> in >>> without the formal stuff of documenting all this, so I guess we can >>> punt the decision about whether to deprecate feeds.Feed or not, but >>> we >>> do need those docs at some point so we can see the implications of >>> deprecating feeds.Feed. >> >> I've gone through my changes and documented exactly what has changed >> as far as the user is concerned. The old API should be completely >> backwards compatible; the new Feed view certainly isn't. >> >>> >>> So for now, maybe just update the release notes so they don't say >>> that >>> the new LatestEntries class is identical to before, or a caveat like >>> "if you are only using the high level feed framework (the feed() >>> view)" or something. >>> >> >> I've gone a little further than that in the patch I've just put on >> the ticket (1), but this probably needs documenting in more detail. >> >> Thanks
Re: 1.2 beta?
On 25 Jan 2010, at 18:55, Jacob Kaplan-Moss wrote: Are we on track for releasing a 1.2 beta this week? That'd match our original schedule, but we did miss 1.2 alpha by a week or so, so perhaps we should push back the beta to match? Or is everyone happy with progress to date and ready to lock things down? I suppose it's too late for #12403 isn't it? http://code.djangoproject.com/ticket/12403 Ben -- 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: 1.2 beta?
On 27 Jan 2010, at 15:36, Russell Keith-Magee wrote: > > However, my initial impression: one way to dramatically increase your > chances is to make sure the patch applies to trunk, and passes all the > tests. Neither of these things are true at present. Using the most > recent patch on the ticket, I currently get 4 patch failures. Once I > fix those the way I suspect they are meant to be fixed, I get a failed > test case (SyndicationFeedTest.test_add_domain). Oh gosh, sorry, I thought I fixed all those problems. I'll get it fixed against trunk this evening. Ben -- 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: 1.2 beta?
On 27 Jan 2010, at 22:50, Ben Firshman wrote: > > On 27 Jan 2010, at 15:36, Russell Keith-Magee wrote: >> >> However, my initial impression: one way to dramatically increase your >> chances is to make sure the patch applies to trunk, and passes all the >> tests. Neither of these things are true at present. Using the most >> recent patch on the ticket, I currently get 4 patch failures. Once I >> fix those the way I suspect they are meant to be fixed, I get a failed >> test case (SyndicationFeedTest.test_add_domain). > > Oh gosh, sorry, I thought I fixed all those problems. I'll get it fixed > against trunk this evening. http://code.djangoproject.com/ticket/12403 I've added syndication-view-6.diff which should apply cleanly against r12313, fixes that test and has a few documentation tweaks. You can see a working pretty diff on github: http://github.com/bfirsh/django/commit/1fac8441b49f690094026fb06189d4f12babac4e Ben -- 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: Class based generic views in 1.3?
On 11 May 2010, at 01:37, Russell Keith-Magee wrote: > > > Are class-based views planned for 1.3? Well, we haven't done any > formal planning for 1.3 yet, but I'm going to guess that the 1.3 high > priority feature list will essentially be "the features that got > dropped from 1.2", so in all likelihood, yes. However, that doesn't > mean that they will definitely be in 1.3 - someone still needs to do > the implementation. If you really want class based generic views, be > like Ben and make it happen -- show us the code!. Oooh, class-based views. This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;) Ben -- 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: Class based generic views in 1.3?
If a class-based view by definition is instantiated on each request, we get a
couple of neat things. For example, storing state on self.
Storing state on self makes things a heck of a lot easier. We are going to
create a "View" and a "ResourceView". A View just renders a template, but a
ResourceView has some kind of resource attached to it (model instance,
QuerySet, whatever). On View, this would be the get_context() signature (where
args and kwargs are from the URL):
def get_context(self, request, *args, **kwargs):
When we create ResourceView, we need to pass the resource in here somehow,
interfering with args and kwargs:
def get_context(self, request, resource, *args, **kwargs):
We would have to redefine all the methods which require the resource. It seems
neater to store it on self.
We have solved accidentally instantiating the view by raising an exception if a
View instance is called twice. Of course, people who understand the threading
issues are free to create their own class-based views.
I like this method because of its transparency. I fear having to explain
as_view() in the documentation. Thread problems are hard to understand.
Ben
On 28 May 2010, at 16:51, Jacob Kaplan-Moss wrote:
> This is a bit of a tricky thing to discuss since we've been talking
> about this IRL at the sprints, and also on the list. I'll try to sum
> up where we are now, but if anything isn't clear, ask.
>
> We're currently working towards URLpatterns of the form::
>
>('...', SomeView)
>
> i.e. passing a class directly, which would be instantiated implicitly
> then called.
>
> The reason we're trying it this way is thread safety: if a view is a
> class, then people *will* store state on self. So if we have single
> instances in views like we do now, then we're giving folks enough rope
> to hang themselves. By having each request get a fresh instance we
> avoid that problem.
>
> The other alternative we discussed was having the base view class do
> something with threadlocals to make sure state saved on self is
> threadsafe. I vetoed that because I hate threadlocals :)
>
> On Fri, May 28, 2010 at 3:41 PM, Luke Plant wrote:
>> I'm sure that will work. My main reluctance is using isinstance()
>> when it isn't necessary, and having to change the definition of what a
>> 'view' is when it isn't strictly necessary. (A view is no longer
>> simply "a callable that takes a request and returns a response").
>
> I *am* a bit worried by this -- I'm not sure redefining the definition
> of "view" is such a good idea. "A view is a callable or a class with
> callable instances" isn't nearly as simple and nice a recommendation.
>
>> If, however, we encouraged `MyClassView.as_view()` from the start, we
>> can cope with constructor arguments more easily - it changes to
>> `MyClassView.as_view(somearg=something)`.
>
> My only real objection here is that `as_view` is just a bunch of boilerplate::
>
>urlpatterns = patterns('',
>('one/', SomeView.as_view()),
>('two/', SomeOtherView.as_view()),
>('three', YourView.as_view())
>)
>
> I just really don't like the way that looks.
>
> As for accepting extra __init__ arguments: I specifically *don't* want
> to allow this (at least easily) because I want to encourage
> subclassing as the "correct" way of extending views. Yes, this means a
> slight loss of flexibility, but it also means that we're forcing
> people into a more extensible and fuure-proof way of coding, and
> that's a good thing.
>
>> (Either way, it would still be possible to pass in MyClassView() and
>> get thread safety problems, but it's about making mistakes less
>> natural).
>
> ... and either way it's pretty easy to issue a warning if you've
> subclassed ``django.views.View`` (my proposed name for the view base
> class) and re-used it for multiple requests.
>
>> There is also the issue of what to do when you need to add a decorator
>> to someone else's view function.
>
> Again, I want to encourge "subclass it" as the correct answer here.
>
>> Given that, for many Django apps, the view functions are part of the
>> public API that needs to be exported (i.e. hooked into people's
>> URLconfs or wrapped for re-use), I think it would be good to encourage
>> practices which will lead to stable and consistent APIs, and so *not*
>> allow or encourage classes to be used directly in the URLconf.
>
> I think we're in agreement here -- we're both trying to avoid view-ish
> stuff in the URLconfs (a la the old way we used to do generic views
> with dicts in urls.py).
>
> Having played with it for a few years now, though, I'm finding
> subclassing is really the best way to make this happen.
>
> So reusable apps instead of exporting functional views export
> class-based ones; users who want to re-use them import, subclass, and
> extend.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
Re: Class based generic views in 1.3?
Luke, you're absolutely right that changing the definition of a view is a bad
idea, it just seemed the best solution then.
But don't worry, we've changed our minds again! If __call__() creates a copy of
self and calls methods on the copy, as far as I can see it solves all our
problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
An example of how it could work:
http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py
Thanks
Ben
On 29 May 2010, at 00:07, Luke Plant wrote:
> On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote:
>
>> My only real objection here is that `as_view` is just a bunch of
>> boilerplate::
>>
>>urlpatterns = patterns('',
>>('one/', SomeView.as_view()),
>>('two/', SomeOtherView.as_view()),
>>('three', YourView.as_view())
>>)
>>
>> I just really don't like the way that looks.
>
> Agreed. I also think that if you have a mixture of normal views and
> class based view, this is ugly:
>
> urlpatterns = patterns('app.views',
> ('one/', 'some_view_function',
> ('two/', SomeOtherView),
> ('three/', YourView)
> )
>
> and it would be nicer to spell it:
>
> urlpatterns = patterns('app.views',
> ('one/', 'some_view_function'),
> ('two/', 'some_other_view'),
> ('three/', 'your_view')
> )
>
> and have these additional lines in 'app.views':
>
>some_other_view = SomeOtherView.as_view()
>your_view = YourView.as_view()
>
> I know that is just moving the boilerplate around, but it is giving a
> consistent interface. If some code in a re-usable app moves from
> normal views to class based views, they will have to do something like
> this *anyway* for backwards compatibility.
>
> But I can see that if subclassing is the default way of re-using, then
> exporting these functions gives multiple options about how they should
> be re-used, which you are wanting to avoid.
>
>>> There is also the issue of what to do when you need to add a
>>> decorator to someone else's view function.
>>
>> Again, I want to encourge "subclass it" as the correct answer here.
>
> In that case, I guess it would be good to make this hard to do wrong,
> by providing helpers that add the decorator to the right end of the
> list of decorators.
>
> Regards,
>
> Luke
>
> --
> "Oh, look. I appear to be lying at the bottom of a very deep, dark
> hole. That seems a familiar concept. What does it remind me of? Ah,
> I remember. Life." (Marvin the paranoid android)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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.
>
--
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: Class based generic views in 1.3?
On 2 Jun 2010, at 22:31, Luke Plant wrote: > On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote: >> On May 30, 7:24 am, Waldemar Kornewald wrote: >>> Maybe I missed something, but why don't you use __new__ instead >>> of copying the instance? >> >> Here is an example where I used __new__ for class based views in my >> project: >> http://djangosnippets.org/snippets/2046/ >> No __call__ or as_view is needed with this approach. >> I can easily replace a function with a class without changing the >> url configuration. > > This is an interesting approach. The only downside I can think of at > the moment is that implementing __new__() like that really violates > expectations - Python programmers have a fairly strong expectation > that if you do 'x = SomeClass()', where SomeClass is defined as a > class, then x will be an instance of SomeClass. Yeah, this idea came up at the sprints, but it's a little too magic for my tastes. Ben -- 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: Class based generic views in 1.3?
On 3 Jun 2010, at 17:45, Carl Meyer wrote: > On Jun 2, 6:20 pm, Ben Firshman wrote: >> Yeah, this idea came up at the sprints, but it's a little too magic for my >> tastes. > > I dunno... is __new__ really more magic than having a __call__ method > that magically copies the instance you call it on? That certainly > breaks my expectations. > > Django doesn't shy away from "magic" in other areas where it makes for > a usable API. The things that happen to model and form fields > certainly violate the initial expectations of a Python programmer; but > it turns out that most people are happy to write readable models and > don't care what's happening under the hood, and those who do care can > learn a little something about metaclasses. Seems to me that __new__ > is a relatively beautiful solution to a thorny problem: it lets people > use class views in all the same ways they use function views while > maintaining thread-safety, it maintains the "callable that returns > HttpResponse" contract, and most people won't ever see or care about > the "magic" that makes it work. > > +1 for __new__. One advantage of using __call__ over __new__ is passing arguments to __init__. That's handy for lazily configuring views: (r'', DetailView(queryset=Thing.objects.all()) Ben -- 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: Class based generic views in 1.3?
On 16 Jun 2010, at 08:24, daonb wrote: > > As I see it, if we're cloning the view, it should be encouraged. I > forked Ben's code and refactored it so that instead of having the > methods pass 'request' around, use self.request. I believe it made the > generic views more readable and it will help users' make their views > cleaner. My fork is at http://github.com/daonb/django-class-based-views The request is passed round so methods look like views to decorators. Magically dropping it for decorators seems a bit scary. :/ Ben -- 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: #6735 -- Class based generic views: call for comment
I don't think we should worry about documentation nightmares - we could leave most of it undocumented and just expose the bits which look like the current generic views (and a few base views) as the public API. I have added a "how to help" section to the wiki page: http://code.djangoproject.com/wiki/ClassBasedViews Ben On 1 Oct 2010, at 12:25, Andrew Godwin wrote: > On 01/10/10 11:17, Luke Plant wrote: >> Passing things around between '_common' and GET and POST makes a simple >> view much more complex than it needs to be, especially when you have >> various local variables that you now have to assign in some way. In the >> end you will end up just routing it all to the one method: >> >> def GET(self, *args, **kwargs): >> return self._common(*args, **kwargs) >> >> def POST(self, *args, **kwargs): >> return self._common(*args, **kwargs) >> >> This is just 4 lines of annoying boilerplate to undo the dispatching >> that was 'helpfully' done for you. >> >> I would definitely support a 'request' method (perhaps call it >> 'dispatch'?) that allows us to avoid that logic. I suspect that every >> view I've created that used a form would be hampered by having dispatch >> based on HTTP verb done first > > There's nothing stopping Django shipping a base view which just calls a > request method, and then another base view which inherits from that and does > method-based dispatch - we shouldn't add too many classes, else it'll be a > documentation nightmare, but that seems a sensible split. > > Andrew > > -- > 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. > -- 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: #6735 -- Class based generic views: call for comment
Sorry if this is a double post - I think Google Groups gobbling up my messages as spam or something. Thanks to everyone who's helping push this forward. I would get stuck in, but I'm bogged down with work at the moment. A couple of things from the wiki page that need doing: 1) Test coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can specify a model and the form is optional. Ben On Oct 5, 3:43 pm, Jacob Kaplan-Moss wrote: > On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee > > wrote: > > Ok - so to kick the process into the next phase, I've just created a > > Django branch in my bitbucket repo [1] to cover introducing this to > > trunk. > > I gave this a quick review and nothing huge jumped out. Looks good so far. > > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the admindocs tool. And just using functools.wraps (or > the equivalent) is as_view won't exactly work, either: you'll get the > dispatch() docstring instead. > > So unless anyone can think of a reason why it'd be a bad idea, I think > as_view needs to monkeypatch the class's docstring into the returned > closure. Bit of a code smell, but I think it maintains the correct > self-documenting nature of a view, yeah? > > > * Does RequestFactory need to be added to Django's test tools > > (Possibly fixing #9002)? > > I'm not sure it's directly class-based-views-related, but I believe it > should, yes. It's a useful pattern that makes it into a utils module > in nearly every app I write. > > > * Does django.views.generic.utils.coerce_put_post() indicate a change > > that needs to be made in Django? (Is there an existing ticket for > > this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't > really "get" PUT very well. Along the same lines, > request.raw_post_data is terribly named. I don't know that there's a > single ticket anywhere, but I'd like to see a general cleanup here. > > I don't see this as a blocker for class-based views, though: we have a > narrow feature deadline that I'd like to hit, and then a longer > bug-fix period we can use to clean up PUT/POST and such. > > > * Are there any outstanding tickets on generic views that will be > > closed by merging this branch, and do they ask for any features that > > aren't fixed by this branch? > > Almost certainly yes :) > > We could *really* use a volunteer who can wade through the open > tickets, look at all the GV-related tickets, and answer this question > concretely. > > Anyone? Bueller? > > 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: #6735 -- Class based generic views: call for comment
Thanks to everyone who's helping push this forward. I would get stuck in, but I'm bogged down with work at the moment. A couple of things from the wiki page that need doing: 1) Test coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can specify a model and the form is optional. Ben On 5 Oct 2010, at 15:43, Jacob Kaplan-Moss wrote: > On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee > wrote: >> Ok - so to kick the process into the next phase, I've just created a >> Django branch in my bitbucket repo [1] to cover introducing this to >> trunk. > > I gave this a quick review and nothing huge jumped out. Looks good so far. > > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the admindocs tool. And just using functools.wraps (or > the equivalent) is as_view won't exactly work, either: you'll get the > dispatch() docstring instead. > > So unless anyone can think of a reason why it'd be a bad idea, I think > as_view needs to monkeypatch the class's docstring into the returned > closure. Bit of a code smell, but I think it maintains the correct > self-documenting nature of a view, yeah? > >> * Does RequestFactory need to be added to Django's test tools >> (Possibly fixing #9002)? > > I'm not sure it's directly class-based-views-related, but I believe it > should, yes. It's a useful pattern that makes it into a utils module > in nearly every app I write. > >> * Does django.views.generic.utils.coerce_put_post() indicate a change >> that needs to be made in Django? (Is there an existing ticket for >> this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't > really "get" PUT very well. Along the same lines, > request.raw_post_data is terribly named. I don't know that there's a > single ticket anywhere, but I'd like to see a general cleanup here. > > I don't see this as a blocker for class-based views, though: we have a > narrow feature deadline that I'd like to hit, and then a longer > bug-fix period we can use to clean up PUT/POST and such. > >> * Are there any outstanding tickets on generic views that will be >> closed by merging this branch, and do they ask for any features that >> aren't fixed by this branch? > > Almost certainly yes :) > > We could *really* use a volunteer who can wade through the open > tickets, look at all the GV-related tickets, and answer this question > concretely. > > Anyone? Bueller? > > 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. > -- 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: GSOC: More backends for djangosearch
I'm still in exams unfortunately, so this will be brief, but I'd like to hear some thoughts. Imagine a small site without a great deal of traffic or data, and they wish to add search support for a model. Lucene or Xapian are probably overkill, and they may not want to invest time into getting it running. tsearch2 or MySQL full text indexes seem the obvious solution, and I would like to try and implement them, but what about a simple built in index that would be backend independent? Much like the django-search "simple" backend: http://code.google.com/p/django-search/source/browse/trunk/search/backends/simple.py Not that I just want to copy other projects, but it'd would be nice to bring together all the best features of all the Django search solutions that already exist. It would be ideal if the developers of all these projects (django-sphinx in particular seems the most mature) would be willing to assist with djangosearch. With their expertise on their search backends, we can make it contrib worthy. Thoughts? Oh and by the way - by the end of next week I should be able to start working. At last! Ben On 3 May 2008, at 22:33, Ben Firshman wrote: > > Hello all! > > A quick introduction: I have been accepted to the GSoC to work on > Django. I will be working on the djangosearch app > (http://code.google.com/p/djangosearch/ > ), in particular adding support for addition search backends, mentored > by Joseph Kocherhans. > > I will spend time getting Lucene and Xapian working well, and I have > an interest in getting Sphinx working too. The app is lacking > particularly in documentation, something I hope I can work on too. > > Due to exams, I can't begin working properly until mid-June, so all > the better for getting input from you! I would be very interested in > hearing what you would like to see from a search application, what > backends you want/are using and any other comments/suggestions you may > have. > > Thanks! > > Ben > > > --~--~-~--~~~---~--~~ 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: More backends for djangosearch
On 20 Jun 2008, at 21:28, Gabriel Sean Farrell wrote: > > On Thu, Jun 19, 2008 at 10:47:36PM +0100, Ben Firshman wrote: >> Not that I just want to copy other projects, but it'd would be nice >> to >> bring together all the best features of all the Django search >> solutions that already exist. It would be ideal if the developers of >> all these projects (django-sphinx in particular seems the most >> mature) >> would be willing to assist with djangosearch. With their expertise on >> their search backends, we can make it contrib worthy. > > As a developer on a Django/Solr project [0], I'm keen on the > possibilities for integrating search engines with Django. A couple of > questions: > > 1. You mention integration with Lucene. Do you mean to do this via > Solr > or PyLucene? Solr is fully working. PyLucene is being worked on. > > > 2. What's the relationship between django-search [1] and > djangosearch [2]? > Seems like some collaboration/combination could happen there. > Er, not sure to be honest, if someone could fill me in on this one it would be handy. Was there some design decision that caused it to go two ways? Ben --~--~-~--~~~---~--~~ 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: More backends for djangosearch
A quick update! School things are well and truly out of the way now, so I can get to work. I have written a mysql full-text backend, and I am now working on a tsearch2 backend. http://code.google.com/p/djangosearch/source/browse/branches/soc-new-backends/djangosearch/backends/mysql.py I will also aim to complete a Xapian backend by the end of the summer. If there is time, I will try other backends, such as Sphinx etc. Are there any other backends anyone wants implemented? Ben On 3 May 2008, at 22:33, Ben Firshman wrote: > > Hello all! > > A quick introduction: I have been accepted to the GSoC to work on > Django. I will be working on the djangosearch app > (http://code.google.com/p/djangosearch/ > ), in particular adding support for addition search backends, mentored > by Joseph Kocherhans. > > I will spend time getting Lucene and Xapian working well, and I have > an interest in getting Sphinx working too. The app is lacking > particularly in documentation, something I hope I can work on too. > > Due to exams, I can't begin working properly until mid-June, so all > the better for getting input from you! I would be very interested in > hearing what you would like to see from a search application, what > backends you want/are using and any other comments/suggestions you may > have. > > Thanks! > > Ben > > > --~--~-~--~~~---~--~~ 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: More backends for djangosearch
On 8 Jul 2008, at 03:17, Rajeev J Sebastian wrote: > > The latest PG has its own text indexing/search system ... is this what > you are referring to by "tsearch2" ? > Yes, exactly. http://www.sai.msu.su/~megera/wiki/Tsearch2_83_changes There do appear to be naming differences between the 8.2 contrib version and the one built into 8.3. Maybe a legacy option is needed? Ben --~--~-~--~~~---~--~~ 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: API change in set_cookie for 1.0?
On 16 Jul 2008, at 01:14, Jeremy Dunck wrote: > > On Tue, Jul 15, 2008 at 6:56 PM, Malcolm Tredinnick > <[EMAIL PROTECTED]> wrote: >> >> >> On Tue, 2008-07-15 at 18:49 -0500, Jeremy Dunck wrote: >>> I was using HttpResponse.set_cookie for the first time and annoyed >>> that expires has to be a properly-formatted string. >>> >>> Why not take a datetime and do the formatting in the function? >>> >>> Obviously this is a breaking change, unless we have an isinstance >>> for >>> backwards incompatibility. >> >> Yeah, we should do something sensible if passed a datetime. Can you >> open >> a ticket? > > http://code.djangoproject.com/ticket/7770 > It would be nice if there were global cookie domain/path/secure/age settings that could be applied. Somehow SESSION_COOKIE_DOMAIN doesn't seem suitable, what with sessions being an optional component. Ben --~--~-~--~~~---~--~~ 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: multi-delete and edit form+changelist unification
On 8 Sep 2008, at 13:36, Erik Allik wrote: > > I'm glad this came up, because I would also like to recommend > considering an admin interface for models that use django-mptt. I know > django-mptt is an external project but I think many people are using > django-mptt as it's currently the most popular tree solution available > for Django. > > What do people think? tusk-cms [0] has a fantastic admin interface for django-mptt based around the jQuery nestedSortables widget [1]. I adapted it for use on one of my own projects, and it wasn't too hard. If there's interest, I'll write a patch for django-mptt for a generic admin interface. Ben [0] http://code.google.com/p/tusk-cms/ [1] http://www.bernardopadua.com/nestedSortables/test/widget/ --~--~-~--~~~---~--~~ 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: multi-delete and edit form+changelist unification
On 9 Sep 2008, at 21:40, Matthias Kestenholz wrote: > > On Mon, Sep 8, 2008 at 6:55 PM, Ben Firshman <[EMAIL PROTECTED]> > wrote: >> >> tusk-cms [0] has a fantastic admin interface for django-mptt based >> around the jQuery nestedSortables widget [1]. I adapted it for use on >> one of my own projects, and it wasn't too hard. If there's interest, >> I'll write a patch for django-mptt for a generic admin interface. >> > > Please do that! Unfortunately I don't have any time currently to > clean up > the code and submit it for inclusion but if it gets you started > that's great. > http://code.google.com/p/django-mptt/issues/detail?id=33 That's a start, but it's a bit hackish for my liking. It would be nice if the "fake" ChangeList could be eliminated. Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Search for the ORM and Haystack
Hi all,
For Google's Summer of Code last year, I worked on djangosearch
(http://code.google.com/p/djangosearch/
) with the aim of extending it with more backends. It soon became
clear that the full text support in Django's database backends was
sufficient for most small sites. Considering the "__search" field
lookup already exists, I have since been working on better built in
support:
http://github.com/bfirsh/django/tree/search
This includes support for PostgreSQL in addition to MySQL, searching
across multiple fields, automatic index creation, relevance, admin
full text search and a simple generic search view. A brief example of
the API:
class Article(models.Model):
headline = models.CharField(max_length=100, search_index=True,
search_weight=1)
pub_date = models.DateTimeField()
body = models.TextField(search_index=True, search_weight=0.3)
class Meta:
ordering = ('pub_date', 'headline')
def __unicode__(self):
return self.headline
>>> Article.objects.search('alpha')
[, ]
>>> Article.objects.search('beta')
[, ]
>>> Article.objects.search('beta').order_by('-search__relevance')
[, ]
>>> Article.objects.filter(body__search='prague')
[]
Feedback would be gratefully appreciated. In particular, the
search__relevance field is being hacked into the select at the moment,
and there is no relevance for the __search filter. It could either be
added automatically, or we could possibly use something like
annotate(Relevance('body', 'prague')). Ideas welcome.
Also, if anybody's interested in adding support for SQLite and Oracle,
let me know.
Of course, external engines such as Solr, Xapian, Whoosh and Sphinx
still need support. Daniel Lindsley has recently released a fantastic
search app based on djangosearch called Haystack (http://haystacksearch.org/
). There are some very smart guys working on new backends, so if you
have any interest in external search engines for Django, I would
encourage you to get involved!
http://groups.google.com/group/django-haystack/
I will be at EuroDjangocon, so maybe we should hold a discussion of
some sort if anyone is interested. Search is an area that has been
disorganised for a while; new users have no idea where to start.
Ben
--~--~-~--~~~---~--~~
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: Search for the ORM and Haystack
On 19 Apr 2009, at 11:42, mrts wrote:
>
> The feature is much needed, thanks for dealing with this!
>
> However, as for the API, I'd say coupling search to models is
> inadvisable, Django has moved away from that design.
>
> A registry-based approach could be implemented:
I agree this approach is better for external engines, but when just
using SQL indexes, it makes a whole load of sense for it to be
included in the ORM. I see "search_index" as just an extension of
"db_index" and "unique".
filter(column__search=...) already exists, it's just extremely limited
in its current state.
>
> # search in all registered models
search.all().query('alpha')
> [, released>]
>
search.model(Article, Book).query('alpha')
> [, released>]
Using SQL, there's no straight forward way of searching over multiple
models. It could be done with another generic "document" model updated
by signals, but this depends entirely on what fields you want to
search over or filter by, so is quite site specific. I suppose some
sort of magic abstract model could be provided if there is a need.
Thanks for the feedback,
Ben
--~--~-~--~~~---~--~~
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: Feeds as views.
On 24 Apr 2009, at 16:21, zellyn wrote: > > [I wasn't sure whether to post this before or after 1.1 dropped, but > decided to post now, since I'm just looking for discussion and > comments.] > > Django's contrib.syndication app feels different from normal views, > using a dictionary and dispatching by slug, then finding objects by > splitting the rest of the URL into "bits". > > It takes surprisingly few changes to make Feeds respond as normal > views: define the __call__ method on Feed objects. > > Here are the changes required (using pastry.se for its diffing > capability): http://pastry.se/46009/#e46010 > And here's the output of `svn diff`: http://pastry.se/46016/ > > Thoughts, comments, suggestions? Funny you mention it, I've been working on something identical over the past few days. It definitely makes sense. http://github.com/bfirsh/syndication-view/tree/master I took the backwards incompatible approach, with the intention of writing a separate Feed class that hacked in the old methods for backwards compatibility. Ben --~--~-~--~~~---~--~~ 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: Feeds refactoring
On 7 May 2009, at 01:11, Russell Keith-Magee wrote: > > On Wed, May 6, 2009 at 5:33 PM, daonb wrote: >> >> Hi all, >> I'm a part of the Django user group in Israel and we want to have our >> own project, taking a part of the Django project and improving it. >> I've discussed it with Jacob, Adrian and Alex yesterday and they all >> agreed that the feeds module needs refactoring. >> So, if you're working on it now or if you have some design thoughts >> please share. I'm working on it here: http://github.com/bfirsh/syndication-view/tree/master > > I've been doing a bit of feed work lately at work. Here's a few ideas > from my wish list: > > * Builtin support for the full Atom publishing protocol. This is > already logged as ticket (#3569) and was originally accepted for v1.1, > but got delayed in the interest of the schedule. > * Named URLs for feeds > * Deploying at arbitrary URLs, rather than /feed/// > * Member per-feed permissions 2nd and 3rd issues are fixed, 4th is straight forward. At the moment I'm working on backwards compatibility and tests, I'll have a go at Atom support unless anybody else is interested. Ben --~--~-~--~~~---~--~~ 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: Feeds as views.
On 3 Aug 2009, at 14:50, Alex Gaynor wrote: > > Ben Firshman has written similar code that is backwards compatible > with the current implementation: > http://github.com/bfirsh/syndication-view/tree/master > > Alex I started going through all the syndication tickets and fixing them too, notably making Atom support complete. Now 1.2 is underway I'll finish it off. Does anybody have any opinions on the current way of using methods on the Feed object (title(), link(), description() etc) to build the feed? For me, it has proved inflexible and a little messy, but I can't think of a better solution. Ben --~--~-~--~~~---~--~~ 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: Feeds as views.
On 4 Aug 2009, at 00:50, Russell Keith-Magee wrote: >> >> >> Does anybody have any opinions on the current way of using methods on >> the Feed object (title(), link(), description() etc) to build the >> feed? For me, it has proved inflexible and a little messy, but I >> can't >> think of a better solution. > > Can you elaborate on the inflexibilities you have seen? When I've hit > problems with Feeds, it's been mostly due to the 'bits' parsing - the > individual feed elements have fallen out reasonably easily. There's no elegant way to add custom elements/attributes to the feed. It is possible using the lower level feedgenerator, but it's not elegant by any means. I'll have a think about it... Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django + SQLAlchemy as a potential GSoC project
I have been considering Django + SQLAlchemy as a potential summer of code project. I understand there is a branch which has gone nowhere and this project: http://code.google.com/p/django-sqlalchemy/ I have read numerous comments on here about either entirely replacing the current database code with SQLAlchemy or at least providing it as an official alternative. What is the current consensus on this? Would proposing a complete replacement be a tad too controversial for a GSoC project? I'd be interested to hear your views. Thanks, Ben --~--~-~--~~~---~--~~ 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 + SQLAlchemy as a potential GSoC project
On 24 Mar 2008, at 20:48, Rob Hudson wrote: > > On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote: >> >> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> >> wrote: >>> Would proposing a complete replacement be a tad too controversial >>> for a GSoC >>> project? >> >> >> Yes. It also wouldn't succeed as a project, because it's the Google >> *Summer* of Code, not the Google Several Years of Code. > > And it sounds like 'empty' and 'brosner' are making good headway on > it... > http://blog.michaeltrier.com/2008/3/21/django-sqlalchemy > Yes, but that is intended as purely a separate plugin, not as something part of Django. The code is there, it would just be a matter of figuring out the logistics (and politics!) of working it into the official distribution. Ben --~--~-~--~~~---~--~~ 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 + SQLAlchemy as a potential GSoC project
OK, thanks for the help. I did trawl through many threads on SQLAlchemy - I couldn't find any conclusive answers! Ben On 25 Mar 2008, at 10:12, Malcolm Tredinnick wrote: > > > On Tue, 2008-03-25 at 19:14 +1100, Malcolm Tredinnick wrote: > [...] >> >> Also "navigate politics to get something accepted into trunk that >> isn't >> particularly wanted at this time" isn't a Google Summer of Code >> project >> and we're not likely to bless a project that covers ground already >> being >> ably done by some other people. If you want to contribute to Django >> there are many things that aren't already being duplicated somewhere >> else. Please pick one of those (or head on over to django- >> sqlalchemy and >> help them out). > > Re-reading this now that the great Internet has finally delivered it > back to my INBOX, I realise it came across more harshly than I > intended. > > By all means submit a proposal on something for working on Django for > Summer of Code. By all means work on SQLAlchemy + Django if that's an > area you wish to contribute to. In the latter case, however, it would > probably be better to work with the existing project, since they're > going about things in a way that gels nicely with Django. The problem > there is that working on something "in conjunction with others" > doesn't > work for Summer of Code, since it's important to be able to tell what > the student did on their own -- those are Google's rules. > > However, if you're going to submit a Summer of Code application, it > should be something that helps move Django in a direction we're > wanting > to go. Go with the flow, not across the stream. Google pay you to help > Django. > > So please don't be discouraged from applying for Summer of Code from > this thread. But do your research and see what's already been > discussed > and what consensus has been reached in any area you're considering > (ask > questions here, by all means, if your research is inconclusive). > > Best wishes and good luck with your application, > Malcolm > > -- > What if there were no hypothetical questions? > 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 -~--~~~~--~~--~--~---
TextIndexingAbstractionLayer and FullHistory branches for GSoC
http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer http://code.djangoproject.com/wiki/FullHistory I see both were on the GSoC list for last year, but neither have been touched in a year. On this list, the last mentions of both branches were a while back too, and nothing conclusive seems to have been mentioned. What's the status on both of them? Do they still need to be finished? Do you think they would be good GSoC projects? Thanks Ben --~--~-~--~~~---~--~~ 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: TextIndexingAbstractionLayer and FullHistory branches for GSoC
On 27 Mar 2008, at 19:46, Jacob Kaplan-Moss wrote: > > Starting from those branches? No. The state-of-the-art has moved on, > and we've gotten wiser about how we maintain open projects. Search, > for example, has a couple of third-party apps out there; working on > any of 'em would make a good proposal. Full history isn't actually all > that much work; look for Marty's AuditTrail (on the wiki) and you can > see he's 80% of the way there in a few hundred LOC. Still, the last > 20% is enough work that a project making AuditTrail into a bonafide > extension might be good. So are you saying I should submit neither as a GSoC project? From last year, I see much work was done on packaging Django apps ( http://code.google.com/p/django-reusableapps/ , http://code.google.com/p/django-package/ ), but was there any ever progress with the application repository? Is this still desired? Maybe I should just give in and pick a project from the '08 ideas list. ;) As an aside, I have so far come across 3 dead branches, shouldn't they be removed? Ben --~--~-~--~~~---~--~~ 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: TextIndexingAbstractionLayer and FullHistory branches for GSoC
On 27 Mar 2008, at 19:46, Jacob Kaplan-Moss wrote: > Still, the last > 20% is enough work that a project making AuditTrail into a bonafide > extension might be good. Sorry, skipped over your last sentence before I sent the last message! I will investigate AuditTrail some more... Ben --~--~-~--~~~---~--~~ 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 proposal: Resource-based Models
I am also extremely interested. This is exactly what I need for a project I'm currently working on and one I may be working on for this year's SoC. Let me know if it gets accepted - I'd love to discuss it with you and I can help test. Thanks Ben On 2 Apr 2008, at 01:09, [EMAIL PROTECTED] wrote: > > Introduction of resource-based Models > = > > My name is Sebastian Hillig and I currently study IT Systems > Engineering in Potsdam/Germany at the Hasso Plattner Institute. > > I came to Django when exploring the "world" of web frameworks about > 1.5 years ago and gladly got stuck to it. Therefore I am interested in > taking part in Google Summer of Code for Django. > > The Proposal > > > Models in Django are conceputally based on tables in a database. I'd > like to enhance that with the introduction of resource-based models. > The basic idea comes from Ruby on Rails' ActiveResource, which allows > for interaction between two sites through a RESTful API. I would like > to take this a step further and provide an implementation of this type > of interface not bound specifically to REST. The interface will be > generic enough to allow for different types of sources. > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSOC: More backends for djangosearch
Hello all! A quick introduction: I have been accepted to the GSoC to work on Django. I will be working on the djangosearch app (http://code.google.com/p/djangosearch/ ), in particular adding support for addition search backends, mentored by Joseph Kocherhans. I will spend time getting Lucene and Xapian working well, and I have an interest in getting Sphinx working too. The app is lacking particularly in documentation, something I hope I can work on too. Due to exams, I can't begin working properly until mid-June, so all the better for getting input from you! I would be very interested in hearing what you would like to see from a search application, what backends you want/are using and any other comments/suggestions you may have. Thanks! Ben --~--~-~--~~~---~--~~ 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: More backends for djangosearch
On 4 May 2008, at 02:24, Leo Soto M. wrote: > > > I'm specially interested in your work with Lucene, because it should > be easily adaptable to work on Jython, and Django on Jython is my SoC > project :). > > Will you post status reports to this list once you get started? I'd > like to follow your progress and try to coordinate something once I > get the core Django working flawlessly on Jython. Yes, I will make sure I post regular updates on here. The project will depend on many 3rd party libraries for the backends - I'm not sure how easy it will be to get that all to work on Jython. Ben --~--~-~--~~~---~--~~ 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: More backends for djangosearch
On 4 May 2008, at 07:31, mrts wrote:
> Good luck with the project!
>
> Has something been decided on using db backend full text search
> facilities as a convenient start?
Well, it already has decent support for Solr, and many other backends
have been started.
> The point is that indexers are overkill for smaller projects and they
> may not be available in constrained environments (e.g. shared
> hosting). In this case it should be easy to get going with db-based
> full text search backend and later migrate to a real indexer only by
> modifying settings to activate a different backend, having zero impact
> on the code otherwise.
Postgresql's Tsearch2 looks very possible. I'm not sure about MySQL's
full text support though, it's very limited indeed. I'd be interested
to hear input on this though, I haven't investigated built in full
text support much yet.
> Also, the API should be discussed. I haven't looked into the existing
> djangosearch API (thus I have an untainted view on things :) )
It currently works something like this:
from django.db import models
from djangosearch import ModelIndex
class Article(models.Model):
title = models.CharField(max_length=255)
date = models.DateField()
index = ModelIndex(fields=['title', 'date'])
def __unicode__(self):
return self.title
results = Article.index.search("search query")
Quite simple and clear I think, what are your thoughts?
Ben
--~--~-~--~~~---~--~~
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: More backends for djangosearch
On 5 May 2008, at 14:34, mrts wrote:
> Looks nice, except one (probably most common) use case -- search over
> all indexed fields in all models that have them.
>
> E.g. the following is both cumbersome and ineffective:
>
> class Foo(models.Model):
> x = models.CharField(max_length=255)
> index = ModelIndex()
>
> class Bar(models.Model):
> y = models.CharField(max_length=255)
> index = ModelIndex()
>
> results1 = Foo.index.search("query")
> results2 = Bar.index.search("query")
>
> That's why I proposed search_all(query). For that a common registry is
> required where search_all can look up the indexed fields in all models
> (and that's why I proposed search.register).
>
> Perhaps that has been dealt with somehow in djangosearch, feel free to
> illuminate me :)
For everything:
results = djangosearch.search("query")
or more specific:
results = djangosearch.search("query", models=[Foo, Bar])
Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
