Re: Easy question to the Auth System
I love Django. Sometimes it's a bit dificult to find what you need, but if you find it, it's always simpel. If someone have the same problem just add filter_horizontal or filter_vertical thats all! Am Sonntag, 16. September 2012 18:01:34 UTC+2 schrieb WoHinDu: > > Hey, > > sorry for my bad englisch. Englisch is not my nativ language, but i hope > you can understand it and sorry for the stupid question but i'm new at > Django. > > I have a table called "Event" in this Table i store some events with > title, date/time an a description. > > But how can i "connect" this events with users from the Django Auth > System? > Is it a good idea to do this with a "ManyToMany" relation or not? > > Thanks. > > WoHinDu > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/UOxttk1-Y6wJ. To post to this group, send email to django-users@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.
Re: Easy question to the Auth System
Hi, Use ManyToMany if one event can relate to *several* Users Use ForeignKey if one event relates to a *single* User Cheers, Thomas 2012/9/16 WoHinDu : > Hey, > > sorry for my bad englisch. Englisch is not my nativ language, but i hope you > can understand it and sorry for the stupid question but i'm new at Django. > > I have a table called "Event" in this Table i store some events with title, > date/time an a description. > > But how can i "connect" this events with users from the Django Auth System? > Is it a good idea to do this with a "ManyToMany" relation or not? > > Thanks. > > WoHinDu > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/dDvQhsitipgJ. > To post to this group, send email to django-users@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. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 4:25 PM, Shawn Milochik wrote:
> On Fri, Oct 7, 2011 at 11:15 AM, Tom Evans wrote:
>>
>> I do this a lot, and haven't found any problems with doing so. My main
>> app has no models.py, but has models/{__init__,foo}.py, and it is
>> still found quite happily by syncdb, south, the admin interface, the
>> app template loader etc.
>>
>> Is there a concrete example of a thing that will not work with this
>> structure?
>>
>> Cheers
>>
>> Tom
>>
>>
> If that's the case then I'm wrong. I guess Django just needs to be able to
> import 'models' from the app root. I specifically remember reading that
> 'models.py must exist' whether your app has models or not, or Django won't
> consider it an 'app.' I took that literally. I didn't consider that it might
> be checking by attempting to import rather than checking for the existence
> of a certain filename, and I never tried to do it otherwise.
> Example from docs:
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/ (says
> models.py must exist for tests to be discovered)
> Ticket:
> https://code.djangoproject.com/ticket/4470 (seems to indicate things don't
> work properly without a single models.py file)
> Shawn
>
>
The documentation is incorrect there - the requirement is that you
have a models module in your app, which has been mistranslated into
'you must have a models.py'.
However, that ticket has reminded me of an issue that you will get -
the app_label of your models will be incorrect. I forgot to mention
that I use a base model class for all models in a subdivided app. This
base model provides the correct app_label in its Meta class (which
means if you define a Meta class on your models, then it must derive
from the base model's meta).
Eg:
class BaseModel(Model):
class Meta:
abstract = True
app_label = 'the_app_name'
class Foo(BaseModel):
name = models.CharField(max_length=32)
class Bar(BaseModel):
name = models.CharField(max_length=32)
location = models.CharField(max_length=32)
class Meta(BaseModel.Meta):
unique_together = ( ('name', 'location'), )
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 8:31 PM, Oscar Carballal wrote: > I was watching this thread for a while now, and I've got a question. > > What is the reason to split the models.py file? I mean, I'm currently > working on a django project, and the models are pretty "simple" (I > usually split them into apps) the biggest models file has five or six > models in the same file. Should I split it? Why? > > To keep each models file small enough that you can find the model you were looking for quickly, and avoiding a >3k line models.py. One of my apps has >50 models, having all of them in one file would result in too much code in one file for my liking. It splits up the code into nice chunks, making it easier to review, refactor, modify and document. At least that is the idea. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 2:31 PM, Oscar Carballal wrote: > Should I split it? Why? you already have. splitted in apps, which is often the best way. but, since most of the 'business methods' code should be in the model (and not in the views as many PHP-refugees tend to do), sometimes a models.py with just five models can grow significantly. in that case, some extra splitting can help; either turn models.py into a directory, or turn models into thin wrappers for external code (in 'utils.py' or similar) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
I was watching this thread for a while now, and I've got a question. What is the reason to split the models.py file? I mean, I'm currently working on a django project, and the models are pretty "simple" (I usually split them into apps) the biggest models file has five or six models in the same file. Should I split it? Why? 2011/10/7 Javier Guerra Giraldez : > On Fri, Oct 7, 2011 at 1:06 PM, bcrem wrote: >> I don't think this format is >> S eccentric that a python purist who comes along later to maintain >> my code can't figure it out pretty quickly. > > nobody said that. what we're saying is: > > 1- one-model/one-file isn't a goal by itself. nothing wrong with > that; but only when justified. > > 2- models.py can be (and often is) split, and there are (at least) > three ways to do it: > > 1.1- turn the file into a module: replace with a directory with an > __init__.py and extra files inside. (this works with any python file, > views.py is another common candidate) > > 1.2- take most non-specifically-model code out to somewhere else > (good when there's significant processing code, or when interfacing > when non-django code) > > 1.3- split in different apps. (usually best to rethink your design, > enhance reusability, reduce coupling, etc) > > -- > Javier > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@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. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 1:06 PM, bcrem wrote: > I don't think this format is > S eccentric that a python purist who comes along later to maintain > my code can't figure it out pretty quickly. nobody said that. what we're saying is: 1- one-model/one-file isn't a goal by itself. nothing wrong with that; but only when justified. 2- models.py can be (and often is) split, and there are (at least) three ways to do it: 1.1- turn the file into a module: replace with a directory with an __init__.py and extra files inside. (this works with any python file, views.py is another common candidate) 1.2- take most non-specifically-model code out to somewhere else (good when there's significant processing code, or when interfacing when non-django code) 1.3- split in different apps. (usually best to rethink your design, enhance reusability, reduce coupling, etc) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
Thanks Bill F - caught my import error when I tried the second
method. Just went back & tried the models/ approach; as long as I
import my classes to a models.py file and add 'models' to
INSTALLED_APPS in settings.py syncdb works fine. So basically I'm
creating a models 'app' without any views to hold my model classes.
It didn't work when I tried importing the classes within the models/
__init__.py file, I must have misunderstood Xavier there.
For the "When in Rome..." comments: sure, point taken. I can
certainly get used to grouping closely associated classes in a single
file. But I certainly don't agree ALL classes belong together, common
practice be damned. I think anyone who's ever worked on a 4000 line
file in some documentation-starved legacy app can see where I'm coming
from. If it's some little stand-alone utility used by two classes out
of a dozen, for example, why pollute the ONE models.py file with it,
so you have to navigate past it all the time to work on the 90% of
models that don't use it? That tool belongs in it's own file, or in
utils.py as someone here suggested. I don't think this format is
S eccentric that a python purist who comes along later to maintain
my code can't figure it out pretty quickly.
Again, thanks for the advice all.
On Oct 7, 12:03 pm, Bill Freeman wrote:
> I think that you want:
>
> from poll import *
>
> in dummy/models/__init__.py
>
> On Fri, Oct 7, 2011 at 11:30 AM, bcrem wrote:
> > The separate models/ directory bit didn't work for me; maybe I'm not
> > understanding what you mean exactly? Here's what I did...
>
> > $ django-admin.py startproject dummy
> > $ cd dummy/
> > $ mkdir models
> > $ vi settings.py
> > ...filled in my db info...
> > $ cd models
> > $ vi poll.py
> > $ cat models/poll.py
> > from django.db import models
>
> > class Poll(models.Model):
> > question = models.Charfield(max_length=200)
> > date = models.DateTimeField('date published')
> > $ vi __init__.py
> > $ cat __init__.py
> > import poll
> > $ cd ..
> > $ python manage.py syncdb
> > ...created the usual django_* & auth_* tables - but no 'poll' table
>
> > However, importing my classes into an otherwise empty models.py worked
> > fine - syncdb generated the tables I was looking for, no problem.
> > Thanks for the quick response everyone.
>
> > On Oct 7, 10:41 am, Xavier Ordoquy wrote:
> >> Hi,
>
> >> Create a models directory and have an __init__.py file within.
> >> Put the models you want to import in that file and you are good to go.
>
> >> Regards,
> >> Xavier.
>
> >> Le 7 oct. 2011 à 16:39, bcrem a écrit :
>
> >> > Howdy,
>
> >> > I come from a C/C++ background, getting into some django/python now.
> >> > I'm used to a one-class/one-file paradigm, and don't much like
> >> > sticking all the models for an app in models.py. It's a minor thing,
> >> > I know...
>
> >> > Is there any way to seperate out these classes, and still have syncdb
> >> > pick them up & update your database for you?
>
> >> > Thanks,
> >> > bc
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Django users" group.
> >> > To post to this group, send email to django-users@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > django-users+unsubscr...@googlegroups.com.
> >> > For more options, visit this group
> >> > athttp://groups.google.com/group/django-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 10:57 AM, Calvin Spealman wrote: > On Fri, Oct 7, 2011 at 10:39 AM, bcrem wrote: >> Howdy, >> >> I come from a C/C++ background, getting into some django/python now. >> I'm used to a one-class/one-file paradigm, and don't much like >> sticking all the models for an app in models.py. It's a minor thing, >> I know... >> >> Is there any way to seperate out these classes, and still have syncdb >> pick them up & update your database for you? > > I suggest you learn to write Python when you are writing Python, and > continue to write C or C++ > when you are writing C or C++. Even in C++, it's quite common to put several related classes in the same source file. the "one class, one file" style is enforced only on Java, AFAIK. there's nothing wrong in splitting modules to prevent them from being unreadable; but in Django, many classes have a declarative style, and keeping them separated would seem too lonely :-( personally, when i see a big models.py, my first idea is to split the whole app, not to split the file and keep a big app. Or, when a models.py (or views.py) starts growing not because of having too many classes; but because there's a lot of functionality on each one, my reaction is to pull code out of the classes and into a 'utils.py', (or something better named) anyway, "when in Python, write as Python do" is really good advice. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
I think that you want:
from poll import *
in dummy/models/__init__.py
On Fri, Oct 7, 2011 at 11:30 AM, bcrem wrote:
> The separate models/ directory bit didn't work for me; maybe I'm not
> understanding what you mean exactly? Here's what I did...
>
> $ django-admin.py startproject dummy
> $ cd dummy/
> $ mkdir models
> $ vi settings.py
> ...filled in my db info...
> $ cd models
> $ vi poll.py
> $ cat models/poll.py
> from django.db import models
>
> class Poll(models.Model):
> question = models.Charfield(max_length=200)
> date = models.DateTimeField('date published')
> $ vi __init__.py
> $ cat __init__.py
> import poll
> $ cd ..
> $ python manage.py syncdb
> ...created the usual django_* & auth_* tables - but no 'poll' table
>
>
> However, importing my classes into an otherwise empty models.py worked
> fine - syncdb generated the tables I was looking for, no problem.
> Thanks for the quick response everyone.
>
>
>
>
> On Oct 7, 10:41 am, Xavier Ordoquy wrote:
>> Hi,
>>
>> Create a models directory and have an __init__.py file within.
>> Put the models you want to import in that file and you are good to go.
>>
>> Regards,
>> Xavier.
>>
>> Le 7 oct. 2011 à 16:39, bcrem a écrit :
>>
>> > Howdy,
>>
>> > I come from a C/C++ background, getting into some django/python now.
>> > I'm used to a one-class/one-file paradigm, and don't much like
>> > sticking all the models for an app in models.py. It's a minor thing,
>> > I know...
>>
>> > Is there any way to seperate out these classes, and still have syncdb
>> > pick them up & update your database for you?
>>
>> > Thanks,
>> > bc
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Django users" group.
>> > To post to this group, send email to django-users@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@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.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 10:39 AM, bcrem wrote: > Howdy, > > I come from a C/C++ background, getting into some django/python now. > I'm used to a one-class/one-file paradigm, and don't much like > sticking all the models for an app in models.py. It's a minor thing, > I know... > > Is there any way to seperate out these classes, and still have syncdb > pick them up & update your database for you? I suggest you learn to write Python when you are writing Python, and continue to write C or C++ when you are writing C or C++. My point is, trends and styles and patterns change as much between languages (and tools) as do syntaxes and APIs, and you must adapt. Remember that you are part of a larger community and code is ready more often than it is written. Don't create frustrating surprises for the next guy. > Thanks, > bc > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@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. > > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
The separate models/ directory bit didn't work for me; maybe I'm not
understanding what you mean exactly? Here's what I did...
$ django-admin.py startproject dummy
$ cd dummy/
$ mkdir models
$ vi settings.py
...filled in my db info...
$ cd models
$ vi poll.py
$ cat models/poll.py
from django.db import models
class Poll(models.Model):
question = models.Charfield(max_length=200)
date = models.DateTimeField('date published')
$ vi __init__.py
$ cat __init__.py
import poll
$ cd ..
$ python manage.py syncdb
...created the usual django_* & auth_* tables - but no 'poll' table
However, importing my classes into an otherwise empty models.py worked
fine - syncdb generated the tables I was looking for, no problem.
Thanks for the quick response everyone.
On Oct 7, 10:41 am, Xavier Ordoquy wrote:
> Hi,
>
> Create a models directory and have an __init__.py file within.
> Put the models you want to import in that file and you are good to go.
>
> Regards,
> Xavier.
>
> Le 7 oct. 2011 à 16:39, bcrem a écrit :
>
> > Howdy,
>
> > I come from a C/C++ background, getting into some django/python now.
> > I'm used to a one-class/one-file paradigm, and don't much like
> > sticking all the models for an app in models.py. It's a minor thing,
> > I know...
>
> > Is there any way to seperate out these classes, and still have syncdb
> > pick them up & update your database for you?
>
> > Thanks,
> > bc
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 11:15 AM, Tom Evans wrote:
> I do this a lot, and haven't found any problems with doing so. My main
> app has no models.py, but has models/{__init__,foo}.py, and it is
> still found quite happily by syncdb, south, the admin interface, the
> app template loader etc.
>
> Is there a concrete example of a thing that will not work with this
> structure?
>
> Cheers
>
> Tom
>
>
> If that's the case then I'm wrong. I guess Django just needs to be able to
import 'models' from the app root. I specifically remember reading that
'models.py must exist' whether your app has models or not, or Django won't
consider it an 'app.' I took that literally. I didn't consider that it might
be checking by attempting to import rather than checking for the existence
of a certain filename, and I never tried to do it otherwise.
Example from docs:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/
(says
models.py must exist for tests to be discovered)
Ticket:
https://code.djangoproject.com/ticket/4470 (seems to indicate things don't
work properly without a single models.py file)
Shawn
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 3:57 PM, Shawn Milochik wrote:
> Tom,
> The 'magic' I was referring to was the check for the existence of a
> 'models.py,' thus preventing you from replacing it with a models directory
> containing __init__.py. That's what a Pythonista would normally do in this
> case. That 'magic' requires you to import the things from models.py instead
> of models/__init__.py.
>
I do this a lot, and haven't found any problems with doing so. My main
app has no models.py, but has models/{__init__,foo}.py, and it is
still found quite happily by syncdb, south, the admin interface, the
app template loader etc.
Is there a concrete example of a thing that will not work with this structure?
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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.
Re: Easy question (I hope)
Tom, The 'magic' I was referring to was the check for the existence of a 'models.py,' thus preventing you from replacing it with a models directory containing __init__.py. That's what a Pythonista would normally do in this case. That 'magic' requires you to import the things from models.py instead of models/__init__.py. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 3:43 PM, Shawn Milochik wrote: > Make as many files as you want, and make sure you import their classes in > models.py so they get picked up by syncdb. > Normally, to do something like this you'd replace the file (in this case > models.py) with a folder named 'models' containing a file called > __init__.py, and import all the additional files' models in __init__.py. > However, there's some "magic" in Django that doesn't consider a folder a > "Django app" unless it contains a file named models.py. > Also, I recommend you don't do any of the above, because as soon as you > start doing things like creating foreign keys and many-to-many relationships > you're going to have a horrific mess, and probably circular imports. > I do almost precisely this in most of my larger apps; I don't have one file per class, rather I keep all closely related models in one file, and haven't hit any problems with this - if you have import issues, then you have the wrong design :) Do you know specifically what magic fails? I hadn't noticed anything. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
On Fri, Oct 7, 2011 at 10:47 AM, Chris Czub wrote: > Shawn -- what do you recommend instead? A friend and I recently had > this debate. His suggestion was to split off as much behavior into > smaller apps with only a handful of models in the models.py as > possible, but I said that if it's not reusable, it shouldn't be an > app. I still haven't found a solution for organizing large-scale > Django app model structures that I'm happy with. > > > The statement that "if it's not reusable, it shouldn't be an app" is patently incorrect. Do what makes sense for your project because it gets the job done and it's as easy as possible to maintain. Any other rules of thumb are only helpful guidelines and shouldn't allow you to go into "analysis paralysis" and not get any work done. I wish I knew who said this first. Hopefully someone will reply to this thread with the info: A good programmer knows when to break the rules. A bad programmer doesn't know he's breaking them. It sounds like you know more than enough to do an excellent job, so go ahead and do it. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
Shawn -- what do you recommend instead? A friend and I recently had this debate. His suggestion was to split off as much behavior into smaller apps with only a handful of models in the models.py as possible, but I said that if it's not reusable, it shouldn't be an app. I still haven't found a solution for organizing large-scale Django app model structures that I'm happy with. On Fri, Oct 7, 2011 at 10:43 AM, Shawn Milochik wrote: > Make as many files as you want, and make sure you import their classes in > models.py so they get picked up by syncdb. > Normally, to do something like this you'd replace the file (in this case > models.py) with a folder named 'models' containing a file called > __init__.py, and import all the additional files' models in __init__.py. > However, there's some "magic" in Django that doesn't consider a folder a > "Django app" unless it contains a file named models.py. > Also, I recommend you don't do any of the above, because as soon as you > start doing things like creating foreign keys and many-to-many relationships > you're going to have a horrific mess, and probably circular imports. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@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. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
Make as many files as you want, and make sure you import their classes in models.py so they get picked up by syncdb. Normally, to do something like this you'd replace the file (in this case models.py) with a folder named 'models' containing a file called __init__.py, and import all the additional files' models in __init__.py. However, there's some "magic" in Django that doesn't consider a folder a "Django app" unless it contains a file named models.py. Also, I recommend you don't do any of the above, because as soon as you start doing things like creating foreign keys and many-to-many relationships you're going to have a horrific mess, and probably circular imports. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question (I hope)
Hi, Create a models directory and have an __init__.py file within. Put the models you want to import in that file and you are good to go. Regards, Xavier. Le 7 oct. 2011 à 16:39, bcrem a écrit : > Howdy, > > I come from a C/C++ background, getting into some django/python now. > I'm used to a one-class/one-file paradigm, and don't much like > sticking all the models for an app in models.py. It's a minor thing, > I know... > > Is there any way to seperate out these classes, and still have syncdb > pick them up & update your database for you? > > Thanks, > bc > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@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. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
Re: Easy question
When you pass in an instance, when you later use the form.save() method, it will save any new data back to that instance. IE, if you pass in both an instance and POST data, it will basically give you a form that merges the instance data with the POST data, and now you can just save back to the instance. If you give just initial data, then I believe when you save it just creates a new object, since it is not bound to any existing object. If you give initial and POST data, then it will merge those together (with the post data winning) and create your new object based on that. Margie On Aug 13, 10:01 am, George Laskowsky wrote: > Hi, > > I was wondering about forms (and modelforms), what is the difference > between passing it an object (in the 'instance' attribute) and passing it an > dictionary with the same data (in the 'initial' attribute)? > > Thanks > -- > George Laskowsky Ziguilinsky --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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 -~--~~~~--~~--~--~---
