Re: Replacing the contrib.sites Site model with a setting?

2016-02-03 Thread Tim Baxter
What would be the recommendation for assigning content to a particular site 
in a shared DB model? Integer field with the current SITE_ID to create a 
sort of faux FK or M2M? Choices?

One thing I like about this pattern I haven't seen discussed already is 
that it would make it far easier to extend Sites as need. For example, one 
request I've had is the ability to store some additional information on 
Sites beyond name and domain. This would provide a pretty straightforward 
mechanism to do so.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53b7ac67-f4c5-4f4a-b175-a3df9172a39c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Some love for admindocs

2015-11-05 Thread Tim Baxter
For the reasons outlined in the comments there, and for the reasons 
outlined by Zan above, I think it should be kept and developed. I believe 
it's one of the most-underutilzed features in Django, and is invaluable for 
both beginners finding their way around and experienced developers who need 
a solid overview of the third-party lib they just grabbed.

Yes, there are shortcomings, but that's reason to improve them, not throw 
them out.


On Friday, September 25, 2015 at 2:05:14 PM UTC-5, Tim Graham wrote:
>
> It might be interesting to fork it and develop your vision as a separate 
> project so you can iterate more quickly. At some point we could evaluate 
> whether the existence of an actively maintained external package would 
> allow us to deprecate the version in Django itself (as has been previously 
> proposed but rejected because it doesn't have a big maintenance overhead 
> and some people like it).
>
> Here's that discussion: 
> https://groups.google.com/d/topic/django-developers/0-qFyCPuSRs/discussion
>
> On Sunday, September 20, 2015 at 8:39:29 PM UTC-4, Žan Anderle wrote:
>>
>> Hi folks!
>>
>> I've been thinking about admindocs lately and that they would really 
>> deserve more attention than they currently get. It's a quite useful feature 
>> and I think a very underrated one.
>>
>> They were initially there to provide documentation for 'front-end 
>> people', when working on templates. While this may still be useful, we've 
>> already discussed that nowadays it's more common to use admindocs as 
>> internal documentation for developers. I think I'd be great if this 
>> position was reaffirmed inside the Django project. Some of the ways we 
>> could do that:
>>
>> 1. Have that position more clearly stated in the documentation for 
>> admindocs
>> 2. Mention admindocs in other parts of the Django documentation. For 
>> example, it seems that following FK relations is often a lot easier with 
>> admindocs. Maybe that should be mentioned somewhere?
>> 3. Mention admindocs in the tutorial. Not sure about this one, since it 
>> could just add unnecessary weight. But it might also make life easier for 
>> some people.
>> 4. Add some possible new features:
>>
>>- documenting management commands 
>>- having some kind of README per app. Tim Baxter provided an 
>> example/possible 
>>implementation 
>>
>> <https://github.com/tBaxter/tango-shared-core/blob/master/tango_shared/views.py#L40>
>>  
>>of this on the irc channel. 
>>
>> Anyway, I'd love to hear your thoughts.
>>
>> Best,
>> Žan
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/117ed8f4-3b64-46d0-9770-053147fedb7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.