Re: Fixing edit_inline on magic-removal

I am +1 on the idea of a feature freeze and was going to make a seperate post on this idea but read this post first. I think there is a lot of good stuff in MR now, and a move towards getting a stable version 0.92 with these features would be brilliant. Naturalyl I want all the future proposed

Re: Fixing edit_inline on magic-removal

Christopher Lenz wrote: > I'm all for a feature-freeze for MR: IMHO the remaining bugs should > be fixed, and the contrib apps (such as comments) updated to the new > API, but *before* there's any more major refactorings. Make another > minor release, and push -- for example -- validation-aware mo

Re: Fixing edit_inline on magic-removal

I'd just like to support these comments as well. moving stuff now to M-R is a bitch, but doable... there are a lot of changes there. at the moment it is easier for me to upgrade my stuff to django M-R, compared to switching to pylons or TurboGears.. if you change to much more than it is probably

Re: Fixing edit_inline on magic-removal

Am 08.03.2006 um 21:06 schrieb Tom Tobin: > On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: >> The patch reverts some changes (such as the removal of core fields) >> which were never really completed. While I'm aware that a much >> improved version of edit_inline is on the way (using Dojo/A

Re: Fixing edit_inline on magic-removal

On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: > > The patch reverts some changes (such as the removal of core fields) > which were never really completed. While I'm aware that a much > improved version of edit_inline is on the way (using Dojo/AJAX and > all that), I think that the branch s

Fixing edit_inline on magic-removal

Hey Djangonauts, I've attached a patch to ticket #1330 that fixes the edit_inline support: The "brokeness" of edit_inline on MR is IMHO the major area that makes the branch unusable to many people. The patch reverts some changes (such as the r