If I seem lunatic, that is just because I just discovered Django.
On 31 tammi, 06:24, Nate Straz <[EMAIL PROTECTED]> wrote:
> With this method we could support the old style of Admin class in
> models and whatever new way we want for extending the ModelAdmin class
> using admin.py in each app.
On Sun, Jan 21, 2007 at 12:24:54PM -0600, Adrian Holovaty wrote:
> On 1/20/07, Honza Kr?l <[EMAIL PROTECTED]> wrote:
> > why not create a function to do that for you..
> > urls.py is after all a python module, so you could just introduce a function
> >
> > urlpatterns = admin_urls_for_model(
> >
On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote:
> There's no reason values useful for more than admin can't be stored in meta.
> There's nothing to stop admin reusing model wide metadata, but it shouldn't be
> polluting the main model file with its own specific settings.
No problem. I agre
Max Battcher wrote:
> The problem with that is that there is a good amount of description
> per model (list_display, et al in the current inner class) that I
> would hate to have to move to other files because I think it mentally
> makes sense to keep with the model because: a) It's "meta-informat
On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote:
> The reason I don't like this is it still leaves models tied to admin, rather
> than the other way around. If someone wants to not have the admin displayed
> for
> a particular app, it should be as easy as deleting or renaming a file, imo,
>
Max Battcher / WorldMaker wrote:
>>ADMIN_FIND_ADMIN_CLASSES = True
>>ADMIN_MODELS = (
>>'myproj.myapp.admin.PollAdmin',
>>'someotherproj.someapp.admin.FooAdmin',
>>)
>
> [...] Let me throw in another option: maybe
> it's time to return to Meta? [...] For instance::
>
> class Meta:
>
On Jan 21, 4:25 pm, "Matthew Flanagan" <[EMAIL PROTECTED]> wrote:
> ADMIN_FIND_ADMIN_CLASSES = True
> ADMIN_MODELS = (
> 'myproj.myapp.admin.PollAdmin',
> 'someotherproj.someapp.admin.FooAdmin',
> )
My 2 (belated) cents on the issue: the settings.py idea is the best
I've seen in the threa
Lachlan Cannon wrote:
> It feels right to me to have admin and the model separate. The way I think of
> it
> is this: Suppose I distribute an app and a user decides to use the app, but
> doesn't run the auto-admin. With my admin information factored out in a
> separate
> file: admin.py, she's no
>
>
> I'm -1 on adding it to URLconf and would rather see it in settings.py.
> Perhaps like:
>
> ADMIN_FIND_ADMIN_CLASSES = True
> ADMIN_MODELS = (
> 'myproj.myapp.admin.PollAdmin',
> 'someotherproj.someapp.admin.FooAdmin',
> )
>
> Where ADMIN_FIND_ADMIN_CLASSES (or whatever we want to call
On 22/01/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/20/07, Honza Král <[EMAIL PROTECTED]> wrote:
> > why not create a function to do that for you..
> > urls.py is after all a python module, so you could just introduce a function
> >
> > urlpatterns = admin_urls_for_model(
> > MyMode
> Something like this is what I had in mind: ...
I generally like the simplicity and explicitness of your suggestion,
but having to manually add & remove models is too fragile, I think.
> Maybe there can be a helper function that looks for all Admin classes, as
> long as you save them in a file
On 1/20/07, Honza Král <[EMAIL PROTECTED]> wrote:
> why not create a function to do that for you..
> urls.py is after all a python module, so you could just introduce a function
>
> urlpatterns = admin_urls_for_model(
> MyModel,
> field_list=[ 'field' ],
> exclude_actions=[ admin.EDIT ],
>
On 1/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/20/07, Robert Myers <[EMAIL PROTECTED]> wrote:
> > However, my latest brainstorm idea is to place an admin-urls.py
> > file in each app which would work just like the generic views and allow you
> > to specify nearly everything. The de
On 1/20/07, Robert Myers <[EMAIL PROTECTED]> wrote:
> However, my latest brainstorm idea is to place an admin-urls.py
> file in each app which would work just like the generic views and allow you
> to specify nearly everything. The defaults of course would be the standard
> options or urls in the
I agree that moving this out of the model would be a great idea. I have been
thinking about this for a long time and not quite sure the best way to
handle it. However, my latest brainstorm idea is to place an
admin-urls.pyfile in each app which would work just like the generic
views and allow you
t
Adrian Holovaty wrote:
> But the bigger question is, should the "class Admin" even live in the
> model at all, given that it's gaining many more hooks, not all of
> which are simple data structures. With each hook I add, it feels more
> and more messy to have that functionality within the model. O
From a puritanical point of view, I would like to see the admin options
separated from the fields. It could also allow for more flexibility. I
think a ModelAdmin class in the same file but separate from the Model
class would be easiest to manage, if that were possible. Assuming the
default use
On 1/18/07, oggie rob <[EMAIL PROTECTED]> wrote:
In the newforms-admin wiki there is mention of a "cleaner way to
specify admin options". Has this been discussed yet?
If so, my apologies. I've kind of been out of the loop for a while.
If not, can we start?
Sure, now is as good a time as any!
Hi all,
In the newforms-admin wiki there is mention of a "cleaner way to
specify admin options". Has this been discussed yet?
If so, my apologies. I've kind of been out of the loop for a while.
If not, can we start?
-rob
--~--~-~--~~~---~--~~
You received this m
19 matches
Mail list logo
