Re: exception handling memory leak...
Thanks for your hard work Keven. There are those of us that appreciate input. On Jun 2, 4:25 pm, Kevin Howerton wrote: > This was not a "hey you guys are lazy", actually came across it ... > after I had fixed the same issue. > > I just posted a patch for you generated off trunk... and left a > hopefully somewhat entertaining explanation of the details surrounding > the issues. > > -k -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal: Build complex-navigation helper
Building a site with more than 50 views tends to require some sort of
sub-sub-page type of system in order to make for easy navigation. For
instance:
/eggs-view/
/eggs-view/sub-view/
/eggs-view/sub-view/sub-sub-view/
/spam-view/
/spam-view/spam-sub-view/
/spam-view/spam-sub-view/spam-sub-sub-view/
/foo-view/
/foo-view/foo-sub-view/
/foo-view/foo-sub-view/foo-sub-sub-view/
Currently, in order to maintain software with this sort of
architecture one can build a tabbed based navigation. The complexity
comes in when you want "sub-view" level tabs to show up only when
you're on "eggs-view", and "sub-sub-view" level tabs to show up when
you're on "sub-view", and so on. This can be done by creating a master
template, inheriting it at each level, and overriding a {% BLOCK MENU
%}. This is OK for small sites, but when you've got 50+ views to
maintain, it means you have sub-sub folders of templates all for the
sake of overriding a single block.
It would be such a relief if a DRY way of configuring a navigation
object existed that allowed for you to build, say, a dictionary of
view-confs with sub-view-confs, etc.
The closest thing I've come across as a solution so far is
http://code.google.com/p/django-nav/
I wonder if anyone in the official D-crew has come up with any ideas
that maybe just need implementing, or perhaps there are others with
this difficulty that would like to see something like this in the
trunk.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Proposal for 1.3 - decoupling a few things in Django a bit.
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): 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. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for 1.3 - decoupling a few things in Django a bit.
I'm sorry. My example is a bit misleading (actually a confusing mess), but the reason for splitting off models into separate was just my idea of a means to an end but probably is a bad solution. I should have started with my business problem instead of mingling my solution into the explanation. Let me start again in a less convoluted manor. The software I started on this month has businesses (which pay to use the software) and it has clients (which are clients of those businesses). The business has one interface at http://manage.example.com and the client has a whole different interface (completely different design and different functionality) at http://clients.example.com. Let's say you have a model ModelXYZ. ModelXYZ instances belong to a client of a business. The client can create, read, update, or delete their ModelXYZ instances. The business who owns the client can also CRUD their client's ModelXYZ instances. The problem is that the views and templates a business is using while editing their client's ModelXYZ instances are completely different from the views and templates that are used by the client to edit the same ModelXYZ instance. The logical thing for me seemed to create a separate app for businesses and one for clients, but I ran into 2 things that made me reconsider: #1) For each set of related models I have to have 2-3 apps (1 for models, 1 for business access, and 1 for client access (unless I decide to put business access into the same app as the models which leads to just two apps)) and #2) Naming conventions are a mess this way. If I have a ModelXYZ (and a few other related models), I might have an app called projects/apps/xzy (which contains models) and two sub-folders of this app; one called project/ apps/xyz/client/, and one called project/apps/xyz/business. Perhaps this isn't so bad. What's your thought. Am I over thinking this, or do you think my solution makes any more sense than after reading my previous post? Thanks Mark On Jun 20, 9:52 pm, Russell Keith-Magee wrote: > On Mon, Jun 21, 2010 at 10:07 AM, M Rotch 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
