> I guess one idea would be to have a tree instead of a list on the side of the
> edit inline stuff
A tree is a good idea. I started playing with something like that, but
it ended up complicating the original solution. I think it's definitely
possible, but maybe as a separate challenge once this
Jacob Kaplan-Moss wrote:
>
> Hey Robert --
>
> As always, great questions...
>
> On Dec 20, 2005, at 8:36 AM, Robert Wittams wrote:
>
>> What are you planning to do with the automatic manipulators? I had
>> planned to make the manipulators "recursive", ie a parent manipulator
>> would hold a l
Hey Robert --
As always, great questions...
On Dec 20, 2005, at 8:36 AM, Robert Wittams wrote:
What are you planning to do with the automatic manipulators? I had
planned to make the manipulators "recursive", ie a parent manipulator
would hold a list of child manipulators for each inline-editab
On Dec 20, 2005, at 8:36 AM, Adrian Holovaty wrote:
How do you envision Ajax use for the edit-inline interface? Would you
be using Ajax simply to return the form widgets for an extra inline
object, or would you be using it to actually *save* the related
objects to the database?
Yeah, the idea
Jacob Kaplan-Moss wrote:
>
> Hey folks --
>
> I'm starting to gear up on the removing core fields bit, and before I
> get too deep into it I want to run my plan by everyone:
>
> First, "core" as a field option will die. Until 1.0 it will be
> accepted and ignored -- but django-admin validate
On 12/19/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> (c) the new edit-inline interface will rely heavily on Javascript
> (AJAX) to do its job.
How do you envision Ajax use for the edit-inline interface? Would you
be using Ajax simply to return the form widgets for an extra inline
object, o
Jacob Kaplan-Moss wrote:
On Dec 19, 2005, at 10:30 PM, oggie rob wrote:
Jacob says:
I kinda think it should be::
class Poll(Model):
...
class Choice(Model):
poll = ForeignKey(Poll)
class ADMIN:
edit_inline_on_relation = 'poll'
But in (almost?) all
Jacob says:
> Yeah, I don't think I explained myself well enough; let me give a concrete
> example of why I'd like this:
Thanks, Jacob, it helps to see things from other perspectives and
especially in that case I agree the gains are well worthwhile.
I was thinking also about how this might work
On Dec 19, 2005, at 10:30 PM, oggie rob wrote:
Jacob says:
I kinda think it should be::
class Poll(Model):
...
class Choice(Model):
poll = ForeignKey(Poll)
class ADMIN:
edit_inline_on_relation = 'poll'
But in (almost?) all other ways the admin section r
Jacob says:
> I kinda think it should be::
>
> class Poll(Model):
> ...
>
> class Choice(Model):
>poll = ForeignKey(Poll)
>
>class ADMIN:
>edit_inline_on_relation = 'poll'
But in (almost?) all other ways the admin section represents the view
for the current
On Dec 19, 2005, at 8:48 PM, oggie rob wrote:
One comment: something that has been bugging me for a while is the
location where you specify the inline behaviour.
For example (using the Poll/Choice models):
class Choice(meta.Model):
poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED,
num_
> Questions? Comments? Concerns?
One comment: something that has been bugging me for a while is the
location where you specify the inline behaviour.
For example (using the Poll/Choice models):
class Choice(meta.Model):
poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED,
num_in_admin=3)
S
On Dec 19, 2005, at 6:55 PM, Eugene Lazutkin wrote:
If you need any help, write me.
I will; thanks.
I would suggest to keep an eye on potential reusability of your
widgets. It
would be nice to use them in custom interfaces.
Yeah, depending on how well it works I might write Dojo widgets
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> (c) the new edit-inline interface will rely heavily on Javascript (AJAX)
> to do its job.
+1.
> Also, this means it's probably time to decide on a JS toolkit to bundle
> with Django and use in the admin. As
Hey folks --
I'm starting to gear up on the removing core fields bit, and before I
get too deep into it I want to run my plan by everyone:
First, "core" as a field option will die. Until 1.0 it will be
accepted and ignored -- but django-admin validate will complain about
it. 1.0 will r
15 matches
Mail list logo
