Re: App portability

2006-09-07 Thread Nate Straz

On Fri, Sep 08, 2006 at 03:18:22AM +0200, Daniel Poelzleithner wrote:
> in myapps/views.py:
> from .models import Somemodel
> 
> which will import from myapps/models.py Somemodel
> 
> from ..otherapp.models import Othermodel
> 
> imports from myapps/../otherapp/models.py -> otherapps/models.py
> 
> This is exactly what we need for our apps to be portable :)

Wow, I never knew about that syntax.  I checked the Language Reference
all the way back to the 1.5 release and it is in every release.  I'm
surprised I've never seen that syntax used before.

Thank you for pointing that out.

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---



Why does the admin app tie directly to models?

2007-01-23 Thread Nate Straz

Why does the admin app tie directly to models?  Why not applications?

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Why does the admin app tie directly to models?

2007-01-24 Thread Nate Straz

On Tue, Jan 23, 2007 at 11:47:08PM -0600, Jacob Kaplan-Moss wrote:
> On 1/23/07 9:16 PM, Nate Straz wrote:
> > Why does the admin app tie directly to models?  Why not applications?
> 
> Because sometimes you want certain models within in app *not* to be 
> admin-editable.

Okay, there's a clue that sometimes customization is needed.  I'll
continue expanding on my idea.

What if the admin app was really an admin framework inside Django?  It
could provide a base admin sub-app that applications could extend.  That
would allow apps to easily add new views to the admin app.

I think it would plug into the urls.py in django.contrib.admin like
this:

  ('^([^/]+)/(?:(.+)/)?$', 'django.contrib.admin.views.main.app_admin')

def app_admin(request, app_label, rest_of_url):
# import admin urlpatterns from app
# continue resolving url with new patterns


Inside app/admin.py:

from django.contrib.admin import AdminApp
from app.models import Foo, Bar

myadminapp = AdminApp(models = (Foo, Bar))
urlpatterns = myadminapp.patterns()


How does that sound for a new direction?

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Why does the admin app tie directly to models?

2007-01-25 Thread Nate Straz

On Thu, Jan 25, 2007 at 06:21:21PM -0600, Adrian Holovaty wrote:
> On 1/24/07, Nate Straz <[EMAIL PROTECTED]> wrote:
> > What if the admin app was really an admin framework inside Django?  It
> > could provide a base admin sub-app that applications could extend.  That
> > would allow apps to easily add new views to the admin app.
> 
> I think you'd find the newforms-admin branch very interesting:
> 
> http://code.djangoproject.com/wiki/NewformsAdminBranch

Yup, I've been following the branch to some extent.  This part:

 96 class ModelAdmin(object):
...
117 def __call__(self, request, url):
...
130 # Delegate to the appropriate method, based on the URL.
131 if url is None:
132 return self.changelist_view(request)
133 elif url.endswith('add'):
134 return self.add_view(request)
135 elif url.endswith('history'):
136 return self.history_view(request, unquote(url[:-8]))

just screams to me that it should use urlconf.

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: specifying newforms-admin options

2007-01-30 Thread Nate Straz

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(
> >   MyModel,
> >   field_list=[ 'field' ],
> >   exclude_actions=[ admin.EDIT ],
> >   perms_required={
> > admin.EDIT : 'can_change_MyModel',
> > admin.LIST : 'something_else'
> >   }
> > )
> 
> I must not have explained this correctly. In the newforms-admin
> branch, all of those options are specified in a class, ModelAdmin. The
> goal here is to figure out how those classes interact with the
> URLconf. There's no need to pass dictionaries around -- all of that
> configuration is in the class.
> 
> Something like this is what I had in mind:
> 
> """
> from myapp.models import PollAdmin, ChoiceAdmin
> 
> urlpatterns = patterns('',
> (r'^admin/', include('django.contrib.admin.urls'), {'models':
> (PollAdmin, ChoiceAdmin)})
> )
> """
> 
> The problem here is that each time you add an admin interface to a
> model, you have to remember to add it to your URLconf. Maybe there can
> be a helper function that looks for all Admin classes, as long as you
> save them in a file called admin.py within the app, but that's kind of
> magic.

What if we made the admin app scan all installed applications in its
urls.py file for admin classes in models or admin modules?

Currently we have this in django.contrib.admin.urls:

# Model-specific admin pages.
('^([^/]+)/([^/]+)/(?:(.+)/)?$', 
'django.contrib.admin.views.main.model_admin_view'),

This pulls us out of urlconf into a view to decide what the real view
is.  Instead we could continue adding to urlpatterns for any admin
classes we find.

# This is pseudo-python
def find_admin_urlpatterns:
for app in settings.INSTALLED_APPS:
if app.admin:
urlpatterns += app.admin.urlpatterns
else:
for model in app.models:
if model.Admin:
urlpatterns += model.Admin.urlpatterns

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.

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Upcoming changes to the Django admin

2007-02-26 Thread Nate Straz

On Sun, Feb 25, 2007 at 12:51:56AM -0600, Jacob Kaplan-Moss wrote:
> Finally, the URLconf.  For the default case (a single admin)::
> 
> ('^admin/', include(admin.site.urls()))
> 
> And for multiple admins::
> 
> ('^admin/', include(admin.site.urls()))
> ('^admin2/', include(second_admin_site.urls()))

Is there going to be any facility for defining additional admin views
besides the current add, change, and delete?

Nate

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---