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

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

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 <b...@firshman.co.uk> 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__ met

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

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

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

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

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 >>

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

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

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? >

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 >>

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 >>

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). > >

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 wa

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 u

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,

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, > #898

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

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

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

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

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 adapt

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

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

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

Re: GSOC: More backends for djangosearch

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:

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

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

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

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

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

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

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

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

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

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 t

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