Re: When to create a new app

Most amazing part about django is every stuff related to a new app! Suppose you may want to create a game and in that first the user have to intimate the move, so for that an app is created ! On 10 Mar 2018 21:40, "Cictani" wrote: > > Hi Andréas, > > thank you. Currently I am working on a db ap

Re: When to create a new app

Hi Andréas, thank you. Currently I am working on a db app for ant species (https://github.com/Cictani/antkeeping_info). Each ant species can be native to several countries and other regions (states for example). I created a separate regions up which contains the models for Country and Region

Re: When to create a new app

Hi Andreas, I would say that this depends on your use case. I try to group functionality or domains in my apps. So for example I have all of the invoicing views and models in one app, all of the user models and views in another app. There are some models that have relationships to other models in

Re: When to use get_user_model()

It's good future-proofing, in case you ever change the User model in your project. In real life, that's highly unlikely, but where it's *really important* to use get_user_model() is when you are writing reusable apps for distribution. If your app is intended to be dropped into any existing Djan

Re: When to use get_user_model()

Thanks Xavier On Mon, Feb 19, 2018 at 1:02 PM, Xavier Paniello wrote: > Hi tangoward15, > > Django will use auth.User as the user model in the system, unless you > change AUTH_USER_MODEL = RegUser in settings.py > > Be carefull, to change the user model has some particularities you can > read in

Re: When to use get_user_model()

Hi tangoward15, Django will use auth.User as the user model in the system, unless you change AUTH_USER_MODEL = RegUser in settings.py Be carefull, to change the user model has some particularities you can read in docs (warning section): https://docs.djangoproject.com/en/2.0/ref/settings/#auth-u

Re: When to use get_user_model()

@Mukul Agrawal, thanks, i'll read this. @Xavier, the model in forms.py, does it mean it will use the RegUser class from the models.py? Sorry, I am confuse. On Sun, Feb 18, 2018 at 9:41 PM, Mukul Agrawal wrote: > The answer on this link can also help you in why and when to use > get_user_mode

Re: When to use get_user_model()

The answer on this link can also help you in why and when to use get_user_model(). https://stackoverflow.com/questions/24629705/django-using-get-user-model-vs-settings-auth-user-model On Feb 18, 2018 4:11 AM, "tango ward" wrote: Hi, I am playing around with user registration. I came across a

Re: When to use get_user_model()

Hi tangoward15, The User model by default is auth.User, but you can define a custom one and reference it at settings: https://docs.djangoproject.com/en/2.0/ref/settings/#auth-user-model So, get_user_model() will return the model defined at AUTH_USER_MODEL setting. Salut! El dissabte, 17 febr

Re: When to use get_user_model()

I also checked the documentation of it but I am confuse. It says "Instead of referring to User directly, you should reference the user model using django.contrib.auth.get_user_model(). This method will return

Re: When to use a model property vs. method?

Thanks to everyone (Bruno, Tom, Ethan and Masklinn) for the extremely informative and very helpful replies. I really appreciate all of the professional help. I have a lot to research and need to practice some of these newly learned techniques/concepts... I may be back with more (this time, Django

Re: When to use a model property vs. method?

On Sat, Jun 18, 2011 at 10:01 AM, Masklinn wrote: > On 2011-06-18, at 15:05 , Ethan Jucovy wrote: > > I tend to avoid @property -- it adds conceptual overhead for code > > readers (hiding the fact that a function call is taking place) for little > > gain. > You *do* realize that django model (and

Re: When to use a model property vs. method?

On 18 juin, 15:05, Ethan Jucovy wrote: > I tend to avoid @property -- it adds conceptual overhead for code > readers (hiding the fact that a function call is taking place) for little > gain. Would you say that the way the attribute lookup mechanism and descriptor protocol are used to turn functio

Re: When to use a model property vs. method?

On 2011-06-18, at 15:05 , Ethan Jucovy wrote: > I tend to avoid @property -- it adds conceptual overhead for code > readers (hiding the fact that a function call is taking place) for little > gain. You *do* realize that django model (and form) fields are descriptors, and any access to a model or f

Re: When to use a model property vs. method?

On Thu, Jun 16, 2011 at 2:07 PM, Micky Hulse wrote: > Hello, > > Just curious what the rule-of-thumb is for when it comes to using > model methods vs. properties. For example: > > [code] > > @property > def is_modified(self): >if self.modified > self.created: >return True >return

Re: When to use a model property vs. method?

On 17 juin, 21:24, Micky Hulse wrote: > > I have never used the @classmethod decorator before. I will have to > read up on that one. A classmethod is a method that takes the class itself as first argument, and so can be called either on a class or instance. It's very handy for alternate constru

Re: When to use a model property vs. method?

Hi Tom and Bruno! Thank you so much for your pro help and assistance. I really appreciate it. :) Replying to both of you in this one e-mail... See inline replies below. On Fri, Jun 17, 2011 at 1:42 AM, Tom Evans wrote: > Access it with MyModel.SEPARATOR or my_model_instance.SEPARATOR Ahhh, I se

Re: When to use a model property vs. method?

On Jun 16, 11:35 pm, Micky Hulse wrote: > > >> def get_separator(self): > >>     return ' :: ' > > In this case (returning a constant), it would be much simpler to make > > it a class (or instance) attribute. > > Ah, I think I get it. > > Just to clarify things for me, does attribute equal a prope

Re: When to use a model property vs. method?

On Jun 16, 11:51 pm, Micky Hulse wrote: > How's this for a rule-of-thumb(?): > > 1. Use a property (class/instance attribute) when an argument(s) is not > needed. Well, a setter does need an argument ;) -- You received this message because you are subscribed to the Google Groups "Django users

Re: When to use a model property vs. method?

On Thu, Jun 16, 2011 at 10:35 PM, Micky Hulse wrote: > Just to clarify things for me, does attribute equal a property or method? :D > > I am guessing that attribute = property, so you're saying that I > could/should do this: > > @property > def separator(self): >    return ' :: ' > No, he's sayin

Re: When to use a model property vs. method?

I am reading through Chapter5+ of Dive Into Python now... Seems like that should cover all of my questions! :D Sorry to bug the list with my ramblings. Thanks again Bruno! Have a great day all! Cheers, Micky -- You received this message because you are subscribed to the Google Groups "Django

Re: When to use a model property vs. method?

How's this for a rule-of-thumb(?): 1. Use a property (class/instance attribute) when an argument(s) is not needed. 2. If an argument(s) is needed (for runtime(?) calculations and/or class/instance attributes need to be sanitized/checked/other), then use a method (or getter/setter/descriptor). No

Re: When to use a model property vs. method?

Hi Bruno! Thank you so much for your help. I really appreciate the pro assistance. :) On Thu, Jun 16, 2011 at 1:42 PM, bruno desthuilliers wrote: > > This could be written much more simply as "return self.modified > > self.created" > Omg, thanks! That's way better. :D >> def get_separator(sel

Re: When to use a model property vs. method?

On 16 juin, 20:07, Micky Hulse wrote: > Hello, > > Just curious what the rule-of-thumb is for when it comes to using > model methods vs. properties. For example: > > [code] > > @property > def is_modified(self): >     if self.modified > self.created: >         return True >     return False Th

Re: When to use a model property vs. method?

On Thu, Jun 16, 2011 at 11:07 AM, Micky Hulse wrote: > Just hoping some of the pro Django/Python users on this list could > school me on this one. :D Actually, here's an example that I am working on now. In my model, I have a CharField that holds the latitude/longitude with values that look like

Re: When to use Form API

This. Form processing is one of those tedious things 90% of which is the same in every form: field definition, display, validation, and error handling/presentation. Django takes care of the repetitive parts, and if you need to customize the validation or display, allows you to do so while still a

Re: When to use Form API

It is important to distinguish between display and functionality with forms. What I mean is, using the forms does not mean you have to render (display) them the way Django has it set up by default. I always use the Form API, and if I need custom validation on a field or the entire form, I overrid

Re: When to use admin, and when not to.

2009/5/27 Andy Mikhailenko > > User behaviour can be formalized as actions + objects. Some actions > span multiple objects. > Admin is a great tool that corresponds the *structure* of data. It > allows to view and edit all your base for great justice. Err, all your > database for zero cost. Out of

Re: When to use admin, and when not to.

User behaviour can be formalized as actions + objects. Some actions span multiple objects. Admin is a great tool that corresponds the *structure* of data. It allows to view and edit all your base for great justice. Err, all your database for zero cost. Out of the box. Nice! However, "editing an ob

Re: When to use admin, and when not to.

On 26 May 2009, at 15:44 , Sieker Adi Jörg wrote: > On 26.05.2009, at 14:28, Sam Kuper wrote: > Also to actually get access to the > admin views, the user needs be flagged as a superuser (I as far as I > remember). > Staff, actually, superuser is another user class (one that gets all admin right

Re: When to use admin, and when not to.

Thanks so much for the comprehensive reply! All best, Sam 2009/5/26 Sieker Adi Jörg > > On 26.05.2009, at 14:28, Sam Kuper wrote: > > > 2009/5/26 Sieker Adi Jörg > > In my humble opinion. As soon as you mention users, the admin is the > > wrong tool. > > contrib.admin is for admin's and not f

Re: When to use admin, and when not to.

On 26.05.2009, at 14:28, Sam Kuper wrote: > 2009/5/26 Sieker Adi Jörg > In my humble opinion. As soon as you mention users, the admin is the > wrong tool. > contrib.admin is for admin's and not for users. > > Another take on it is: > - Anyone that creates an account on your site, doesn't get to

Re: When to use admin, and when not to.

2009/5/26 Sieker Adi Jörg > In my humble opinion. As soon as you mention users, the admin is the > wrong tool. > contrib.admin is for admin's and not for users. > > Another take on it is: > - Anyone that creates an account on your site, doesn't get to ses the > admin > - Anyone that you create an

Re: When to use admin, and when not to.

Hi, On 26.05.2009, at 12:17, Sam Kuper wrote: > 2009/5/26 Alex Gaynor >> It's not even an authorisation issue, it's that I'd be overiding >> nearly every method to make sure the behavior was what I wanted, >> and then I'd replace all the templates since I want everything the >> user sees

Re: When to use admin, and when not to.

2009/5/26 Alex Gaynor > It's not even an authorisation issue, it's that I'd be overiding nearly > every method to make sure the behavior was what I wanted, and then I'd > replace all the templates since I want everything the user sees to be > similarly themed, and at this point I've already rewri

Re: When to use admin, and when not to.

On Mon, May 25, 2009 at 8:25 PM, Sam Kuper wrote: > 2009/5/26 Alex Gaynor > >> On Mon, May 25, 2009 at 7:51 PM, Sam Kuper >> wrote: >> >>> Suppose you were re-writing Facebook in Django. >>> >>> Would you handle the complex profile and privacy settings pages by: >>> >>> A) exposing the relevant

Re: When to use admin, and when not to.

2009/5/26 Alex Gaynor > On Mon, May 25, 2009 at 7:51 PM, Sam Kuper > wrote: > >> Suppose you were re-writing Facebook in Django. >> >> Would you handle the complex profile and privacy settings pages by: >> >> A) exposing the relevant admin pages to users, with careful auth to stop >> users from

Re: When to use admin, and when not to.

On Mon, May 25, 2009 at 7:51 PM, Sam Kuper wrote: > Suppose you were re-writing Facebook in Django. > > Would you handle the complex profile and privacy settings pages by: > > A) exposing the relevant admin pages to users, with careful auth to stop > users from being able to access admin pages the

Re: When to use each of these approaches ?

On Sun, 2009-01-04 at 01:01 -0800, HB wrote: > Hey, > What is the difference between: > query = request.GET.get('q', '') > and > (r'^time/plus/(\d{1,2})/$', hours_ahead) > And when to use each approach? > Thanks guys. > #I'm new to Django, forgive my simple questions :) GET parameters (the first

Re: When to start an app?

Yep, you'll have some overlap, but I think it makes sense to create a separate app wherever the data model/views could logically stand alone. So, user registration would be one app. I'm working on a project that does a lot with demographic data based on user profiles, so profiles is another sep

Re: When to use templatetags and how to use views.py

Hi Malcolm, Thanks for the great writeup, it has certainly made things clearer. Like you say, don't sweat the small stuff - I'll try not to :) Thanks, Chris On Jan 11, 8:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-01-10 at 23:18 -0800, Darthmahon wrote: > > Thanks for th

Re: When to use templatetags and how to use views.py

On Thu, 2008-01-10 at 23:18 -0800, Darthmahon wrote: > Thanks for the reply, I've also just found out about context > processors, which to me sound extremely similar to templatetags. The > only problem I can see with both of these options is that I can't see > how you pass extra options into them

Re: When to use templatetags and how to use views.py

Thanks for the reply, I've also just found out about context processors, which to me sound extremely similar to templatetags. The only problem I can see with both of these options is that I can't see how you pass extra options into them, whereas you can if the logic is contained within views.py I

Re: When to use templatetags and how to use views.py

On 10-Jan-08, at 8:54 PM, Darthmahon wrote: > Is there any real difference between passing the data from a views.py > file into a template compared with asking for the data using a > templatetag? if you are only using it in one template - do it in the view. If you are doing it in several or a

Re: When to use Admin Forms and/or Generic Views and/or New Forms ?

On 7/4/07, Vizcayno <[EMAIL PROTECTED]> wrote: > > Hello: > I know that Django provides 3 ways in using Web forms: Admin Forms, > Generic views and New Forms where Admin forms is the easiest one to > use. > What I would like to know is: > 1) Which determinant aspects should force me to use Generic

Re: When to restart Apache?

* Rob Slotboom wrote, On 12.02.2007 10:25: > When running Django using mod_python you have to restart Apache > whenever you make changes to your code. Some changes don't require a > restart so I wonder which changes trigger mod_python to reload and > which don't. Basically any change to the pytho

Re: When to

On 13/10/06, MerMer <[EMAIL PROTECTED]> wrote: > > I can see that I could use inclusion tags or template tags. I've read > the documentation however, I'm still unclear when you would use one > over the other. > > What would be the appropriate use case for a template tag versus an > inclusion tag

Re: When to

I can see that I could use inclusion tags or template tags. I've read the documentation however, I'm still unclear when you would use one over the other. What would be the appropriate use case for a template tag versus an inclusion tag? MerMer --~--~-~--~~~---~--~

Re: When to

Frankie, Thanks for this... I'll take a look. MerMer --~--~-~--~~~---~--~~ 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 thi

Re: When to

On 12/10/06, MerMer <[EMAIL PROTECTED]> wrote: > > As a follow on. Can I:- > > Combine all three templates by using inheritance between the templates. > > Unfortunately, I haven't been able to test this yet - because I can't > get the "extend tag" to work (see other post).I am assuming that i

Re: When to

As a follow on. Can I:- Combine all three templates by using inheritance between the templates. Unfortunately, I haven't been able to test this yet - because I can't get the "extend tag" to work (see other post).I am assuming that it won't work because of the following. Could someone confir

Re: When to use django.db.models.LazyDate() and when datetime.now()?

Thanks Luke, very nicely explained! Rudolph --~--~-~--~~~---~--~~ 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, s

Re: When to use django.db.models.LazyDate() and when datetime.now()?

On Friday 09 June 2006 13:35, Rudolph wrote: > Hi, > > I understand why we have the django.db.models.LazyDate(): it's to > make sure we get the datetime value at execution time and not at > "compile" time. The docs tell you to use it for "limit_choices_to", > but should I also use it when I want t