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 se
e.
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
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,
>
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 f
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,
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 depre
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).
>
> Firs
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
&g
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 oppor
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?
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 th
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
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
>> test
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 li
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
Resourc
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 boile
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 use
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
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
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
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 prob
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 s
phinx 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
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
&g
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:
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 c
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 p
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 po
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
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 t
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
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 dispatchi
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, Adri
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
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 bett
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 c
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
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 ac
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 conclusiv
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 pr
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
--~--~--
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]
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 Luce
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 you
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
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
46 matches
Mail list logo
