> I'm yet to see a genuine case of (a) -- every time I've seen (a), it's
> really masked version of (b), (c) or (d).
I disagree. I think there are very specific problems, that has not
been adressed by any of the responses above.
Let's focus on one for now: how to extend models in any given app.
As stated in the original mail, there are at least two problems with
this in Django:
1. How to provide the models in the first place? Everything that's not
abstract is hard to extend; providing abstract models feels really
awkward.
2. How to tie in the models into the views? Long view parameter lists
that are used from urls are ugly and repetitive. Moreover: it may not
be possible to solve the entire problem this way (think admins, think
forms).
If we forget about Django's status quo for a minute and take
extendability of related webfeatures as a goal, an obvious solution
would be using a class. Classes are surely the poster child for
extendability. The class would contain everything that's relevant for
an app: all models, views, admin stuff etc, in addition to the
relevant internal API ('hooks'). Like so:
class AbstractPage(models.Model):
body = models.TextField()
class Meta:
abstract = True
class MyApp(object):
def get_models(self):
# returns something that Django understands, i.e. a list of
Model classes
# or simply lists the models, so that the cache picks up on it
def get_page_class(self):
class Page(AbstractPage):
pass
return Page
def page_detail(self, request, pk=None):
page = self.get_page(pk)
# or:
page = self.get_page_class.objects.get(pk=pk)
return render_to_response('myapp/page_detail.html', locals())
def get_urls(self):
# something that can be included by django
Obviously we can choose anything that python permits to create
organization of the above once it starts growing. Standardization
would be a good idea as well.
However, the main point is that a structure like the above would allow
for very simple extension on the app level, like so:
class CustomizedMyApp(object):
def get_page_class(self):
class Page(AbstractPage):
title = models.CharField(max_length=255)
return Page
AFAIK this is currently not possible. But I may be misinformed.
The main stumbling block is that an app is somehow special to Django,
specifically in that it is a directory, containing a file 'models.py'.
The name of the app directory is included in INSTALLED_APPS in your
settings.py. I guess other stuff might break as well (do urlpatterns
and reverse views work for any method, rather than functions in the
top level of a module?).
Django's idea of apps is great, because it gives us such an easy way
to start. However, I think it breaks down in the above example. Would
it be possible to rewrite Django so that the INSTALLED_APPS way of
working would remain available, but would be a shortcut/facade to a
manual registration of the various parts that entail an app? I think
so.
Hope to hear from you all, I will play a bit with some code in the
meantime.
p.s.
Thinking about it some more: it's not weird at all that apps are hard
to extend, since apps are limited to being modules. Modules are not a
unit for extension.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
