Ohh, I like that idea, so basically you mean a way to allow installed apps to have an effect on what startapp gives you initially. I really like that idea a lot. I am all about making things easier.
While we are on the topic does anyone think that there is any other ways to make startapp be smarter? Obviously we don't want it to be cumbersome and over step its bounds, but are there other things that could be assumed from a projects context that startapp could use to make your life easier. I really don't like to have to copy and paste things on a regular basis. * Adding urls,py *I looked through the mailing list earlier and saw that having urls.py be added as well was an idea in the past. For me it doesn't seem to me to be a hard enough rule to go on because I don't seem to use it most of the time, but what does everyone else think? *Importing get_text() to your models files as _* Another idea could be if you have more than one language in your languages list in settings.py then you are most likely are going to be using the translation's get_text() function in your models.py file. If this assumption is accurate then we could have startapp write in the imports for you. Again, I know it seems lazy but if things like that are automated then it will help people follow the conventional best practices, and It also would feel pretty cool when you ran startapp and it worked for you. Rather than having to think, "okay..... what do I need to import here again." Is there any other patterns we could gleam to keep us from having to write the same things over again? Cheers, James Hancock On Sun, Jan 2, 2011 at 9:09 PM, Russell Keith-Magee <russ...@keith-magee.com > wrote: > On Sunday, January 2, 2011, James Hancock <jlhanc...@gmail.com> wrote: > > Django-dev, > > > > I know this is probably just lasy, but can we have startapp check if > admin is installed and if it is, add an admin.py file? > > > > If it isn't safe to assume then I understand not doing it, but it seems > that if you have the admin installed and you create a new app you normally > use admin.py somehow. > > > > What do you think? > > > > I thought I would post here because it probably has some far reaching > effects somewhere that I would have never thought of. It always seems to. :) > > In this case, it's just a matter of something that nobody has put the > effort into writing the code. The idea has been proposed (at least > informally) in the past. It hasn't been a very high priority because > creating a new admin.py file isn't *that* hard, so implementing this > particular feature has taken second place to more substantial changes. > > The only implementation detail that has been discussed in the past > (that I'm aware of) is that admin.py shouldn't be created unless admin > is actually installed, but you've already covered that. The other > suggestion I have would be to implement the feature as a general > facility that any app could hook into, rather than a special case for > contrib.admin. A signal emitted by the startapp command would be one > option here. > > 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 django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
