On Mon, Jun 21, 2010 at 10:07 AM, M Rotch <[email protected]> wrote: > I just have a few practical ideas that I want to lay out, pertaining > to loose coupling. > > I've worked with Django for a while and one of the things I love is > that you can do things your own way, instead of having the > constricting requirements that "convention over configuration" brings > (like in Rails). Django does enlists a few "convention" requirements > if you want to make things easy and automatic. This is fine unless you > need to do it the non-automatic way (larger applications bring this > need up). > > There are a few areas where this comes up but I'll only touch on the > most obvious: > > When you're building an application that has many related data models > and different types of users that have many views which access data > from multiple apps, it becomes really easy to forget where you put > certain models and seems disorganized. > > Splitting things up into more and more apps doesn't fix the problem, > because having apps that only serve as a host for views and apps that > only serve as a host for models makes a mess in larger applications. > What does fix the problem is keeping a taxonomy that makes sense for > your business; data models based on where they belong and views based > on who/what they're for (e.g. data models in ``project/data/company/ > models.py``, views that access those models in ``project/views/clients/ > tickets.py`` and ``project/views/company/dashboard.py``). > > > My proposal (This solution could be way off but I'm really wanting to > hear what others think about the problem in general):
My immediate reaction is that this is a solution to a problem that shouldn't exist in practice. If you're in a situation where you have an need to split up your models file for organization purposes, your app is probably getting too large, and you should be considering how to split your application into smaller independent parts. If splitting your project into smaller apps doesn't seem like a feasible solution, then I strongly suspect that you need to look closer at how you are modelling the data in your project. In all the projects that I curate, I very rarely reach a situation where I've had a desire to split models.py into smaller files; the only exceptions are applications that I know I *should* refactor into different apps, but haven't got around to it yet. I haven't seen your project or code, though, so it is possible that this just a limitation of my own experience. > Create a way to manually register a model instead of simply scanning > for models.py in each installed app. The current ``"myapp.MyModel"`` > way of accessing models for foreign keys could be replaced with model > naming much the same way that views can be named. Being able to name > your models and accessing them by name seems better anyways because > then your class name could change but the models "name" would remain > the same, making code changes easier. The first alarm bell that goes off here is backwards compatibility. We can't arbitrarily change the way we refer to models; if we're going to add new features, those features need to be consistent and compatible with existing features. The second alarm bell is the potential for namespacing issues. You seem to be suggesting that the registered name of a model should be completely divorced from the class name (and presumably, the module path). One of the advantages to tying the namespacing structure to the app structure is that you largely avoid namespacing collisions. If you separate these concerns, you suddenly have a bunch of new namespacing problems (e.g., two separate apps that register "user.profile" as a model name). This doesn't fill me with confidence. It's also worth nothing that there is some potential overlap with one of the GSoC projects that is currently underway. I don't expect that the App Loading GSoC project will actually be implementing any of the features you are describing here, but they are playing in very similar sandboxes, so if you were to start writing code in this area, I would expect you to be stepping on toes. This isn't necessarily a reason to avoid working on this, but it is worth keeping under consideration. In summary -- I'm sorry to say that my reaction to this proposal is "meh". In my experience, I haven't experienced this problem as anything other than a reflection of a need for internal refactoring; and the proposal you have made (so far) has a lot of loose ends that need fleshing out. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
