Adrian Holovaty wrote:
I've been wanting to make the "core" and "auth" models optional for
installation, effectively removing the "django-admin.py init" command
and requiring people to install "core" and "auth" explicitly.
I'd say I'm against it. I don't know of any stats but my feeling is t
+1000! I think it's an elegant solution to the stated problem, and
would be immensely useful on its own merits regardless. For example,
I'm using Django to write a lot of custom business logic for an
intranet, and I've already run into the dependencies issue; being
able to explicitly stat
I've been wanting to make the "core" and "auth" models optional for
installation, effectively removing the "django-admin.py init" command
and requiring people to install "core" and "auth" explicitly.
Reasoning: It's messy for the framework to create database tables that
everybody doesn't necessar
On 12/16/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Now that you mention it, I think "Admin" and "Meta" look better,
> though...
I've changed "class META" to "class Meta" in the magic-removal branch.
The former is no longer accepted. I figure since this will be such a
big change, we migh
On 16 Dec 2005, at 21:09, Jacob Kaplan-Moss wrote:
Now that you mention it, I think "Admin" and "Meta" look better,
though...
+1. They're much prettier and improve code readability (a tiny bit)
as well.
> 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
License is BSD so all is well in that regard. There is still an issue
with the app that gets passed to the server to deliver the request
properly. It would be great is there is someone interested in helping
that understands this aspect of Django well that could lend a hand.
Regards,
David
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/20/05, David Pratt <[EMAIL PROTECTED]> wrote:
> Further, if cherrypy wsgiserver is used, the cgi for windows service has
> already been written and get Django a bit futher along for some sort of
> packaging as been suggested for Windows.
Hi David,
This sounds fine to me. If the license is
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
Hi Adrian. I think the first part of this is to get the server to spin
off its thread with a cgi to start and stop. This can then be wrapped
with win32service to make this a windows service as with similar code I
put up the other day. I noticed that Django is already using the
cherrypy autore
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
15 matches
Mail list logo
