Re: Django-compressor manifest.json problem on Heroku

[Guy Tamir]

Hi,

The COMPRESS_OFFLINE_MANIFEST is to set the name of the manifest, default 
is manifest.json
this issue isn't that the server can't find the manifest, it finds the 
correct one but downloads (I think) it every request..

On Tuesday, December 16, 2014 4:49:22 AM UTC+2, Collin Anderson wrote:
>
> Hi Guy,
>
> I haven't used django_compressor, but it might help to configure 
> COMPRESS_OFFLINE_MANIFEST.
>
> Collin
>
> On Saturday, December 13, 2014 11:54:27 AM UTC-5, Guy Tamir wrote:
>
> I haven't configured django caching, how do I do that?
>
> Also - CachedS3BotoStorage is this:
>
> from django.core.files.storage import get_storage_class
> from storages.backends.s3boto import S3BotoStorage
>
>
> from django.core.files.base import File
>
>
> class CachedS3BotoStorage(S3BotoStorage):
> """
> S3 storage backend that saves the files locally, too.
> """
> def __init__(self, *args, **kwargs):
> super(CachedS3BotoStorage, self).__init__(*args, **kwargs)
> self.local_storage = get_storage_class(
> "compressor.storage.CompressorFileStorage")()
>
>
> def save(self, name, content):
> name = super(CachedS3BotoStorage, self).save(name, content)
> self.local_storage._save(name, content)
> return name
>
>
> On Friday, December 12, 2014 5:09:16 PM UTC+2, Collin Anderson wrote:
>
> Hi,
>
> Do you have django caching configured? If not, then caching will only be 
> per-process and each process will need to fetch the information. (I'm 
> assuming CachedS3BotoStorage uses django's cache.)
>
> Collin
>
> On Wednesday, December 10, 2014 11:05:35 AM UTC-5, Guy Tamir wrote:
>
> Hey all,
>
> I'm trying to add django-compressor into my app.
> I'm deploying to Heroku.
>
> This is the code in my Settings file
> AWS_QUERYSTRING_AUTH = False
> AWS_STORAGE_BUCKET_NAME = os.environ.get('BUCKET_NAME')
>
> conn = S3Connection(AWS_ACCESS_KEY, AWS_SECRET_KEY,host="
> s3-us-west-1.amazonaws.com")
> STATIC_ROOT = 'static'
> COMPRESS_ROOT = 'static'
>
>
>
> COMPRESS_CSS_FILTERS = ['compressor.filters.yuglify.YUglifyCSSFilter',
> 'compressor.filters.cssmin.CSSMinFilter']
> COMPRESS_JS_FILTERS = ['compressor.filters.jsmin.JSMinFilter'] 
> #,'compressor.filters.jsmin.SlimItFilter'
> COMPRESS_OUTPUT_DIR = 'compressed'
> COMPRESS_CSS_BACKEND = 'django_compressor.css.CssCompressor'
> COMPRESS_JS_BACKEND = 'django_compressor.js.JsCompressor'
> COMPRESS_OFFLINE = True
> COMPRESS_ENABLED = True
>
>
> if DEBUG:
> STATIC_URL = '/static/'
> else:
> AWS_S3_CUSTOM_DOMAIN = os.environ.get('COMPRESS_URL') # cdn.test.com
> STATIC_URL =  'http://' + AWS_S3_CUSTOM_DOMAIN + '/'
> STATICFILES_STORAGE = 'myapp.CachedS3BotoStorage.CachedS3BotoStorage'
> COMPRESS_STORAGE = 'myapp.CachedS3BotoStorage.CachedS3BotoStorage'
>
>
> COMPRESS_URL = STATIC_URL
>
>
> I ran the compress command locally and then deployed to Heroku.
> When I see my deployed pages I can see in the source files that the 
> browser is using the compressed css and js file like expected.
>
> My problem is that when I see my logs from Heroku, each time that I 
> refresh a page, it seems like Heroku goes and fetches the manifest.json 
> file from my S3 bucket.
> This obviously slows down the requests..
>
> Logs from Heroku:
> 2014-12-10T16:01:14.087225+00:00 app[web.1]: DEBUG:boto:Token: None
> 2014-12-10T16:01:14.086183+00:00 app[web.1]: DEBUG:boto:auth
> _path=/test-dollarsocial/compressed/manifest.json
> 2014-12-10T16:01:14.137618+00:00 heroku[router]: at=info method=GET path=
> "/login/" host=test-dollar-social.herokuapp.com request_id=bede0d95-e9b6-
> 4453-95b3-438606fc7e62 fwd="93.172.158.119" dyno=web.1 connect=1ms service
> =194ms status=200 bytes=13248
> 2014-12-10T16:01:14.051410+00:00 app[web.1]: DEBUG:boto:Using secret key 
> provided by client.
> 2014-12-10T16:01:14.051322+00:00 app[web.1]: DEBUG:boto:Using access key 
> provided by client.
> 2014-12-10T16:01:14.051990+00:00 app[web.1]: DEBUG:boto:path=/compressed/
> manifest.json
> 2014-12-10T16:01:14.052126+00:00 app[web.1]: DEBUG:boto:auth_path=
> /test-dollarsocial/compressed/manifest.json
> 2014-12-10T16:01:14.052405+00:00 app[web.1]: DEBUG:boto:Path: /compressed/
> manifest.json
> 2014-12-10T16:01:14.052316+00:00 app[web.1]: DEBUG:boto:Method: HEAD
> 2014-12-10T16:01:14.052490+00:00 app[web.1]: DEBUG:boto:Data:
> 2014-12-10T16:01:14.052605+00:00 app[web.1]: DEBUG:boto:Headers: {}
> 2014-12-10T16:01:14.052734+00:00 app[web.1]: DEBUG:boto:Host: test-
> dollarsocial.s3.amazonaws.com
> 2014-12-10T16:01:14.052828+00:00 app[web.1]: DEBUG:boto:Params: {}
> 2014-12-10T16:01:14.052970+00:00 app[web.1]: DEBUG:boto:establishing 
> HTTPS connection: host=test-dollarsocial.s3.amazonaws.com, kwargs={
> 'timeout': 70}
> 2014-12-10T16:01:14.053082+00:00 app[web.1]: DEBUG:boto:Token: None
> 2014-12-10T16:01:14.053224+00:00 app[web.1]: DEBUG:boto:StringToSign:
> 2014-12-10T16:01:14.053227+00:00 app[web.1]: HEAD
> 2014-12-10T16:01:14.053228+00:00 app[web.1]:
> 2014-12-10T16

Re: Thinking about EAV database model for flexibility. How (in)compatible is it with the django model?

[Felipe Faraggi]

Thanks for your responses Jamie and Erik,

We've since reconsidered and will in fact, be creating a standard 
relational structure. 

Again, thanks for your input and feedback




On Tuesday, December 16, 2014 2:18:12 AM UTC+1, Jamie Lawrence wrote:
>
> Just to add to Erik's very good advice on (not) using EAV, another thing 
> to keep in mind is that the downsides of EAV tend to manifest after your 
> app is hosting a substantial amount of data, at which point the exercise of 
> sanitizing it in order to port it to a saner model can be *excruciating*. 
>
> I've come in to projects like this as a consultant and the golden rule of 
> any such contract is "no cap on data conversion fees, but please feel free 
> to do it yourself once you realize how much it will cost to preserve that 
> data."
>
> More generally, when using a relational database, you want to think hard 
> about temptations to store things in generic buckets. There is a data store 
> optimized for generic buckets of bits; it is called a file system. Rdbmses, 
> not being designed for that, tend to become expensive[1] when forced to act 
> like it. 
>
> -j
>
> [1] not necessarily in currency, but that can certainly happen as well. 
>
> -- 
> Sent from a phone, please excuse typos and terseness.
>
> On Dec 15, 2014, at 5:42 AM, Felipe Faraggi  > wrote:
>
> Hello everybody.
>
> I am very new to django and I come from a wordpress background (yes, yes I 
> know) and I really like their wp_*meta model. 
>
> After a little digging I discovered this is called the Entity-attribute-value 
> model or EAV 
> . 
> And I am currently setting up a project in django in which my data is very 
> variable because we will be opening up to many APIs and they all have their 
> own table styles. So instead of having a rigid model, we've opted for 
> having a EAV model to stock everything with its own key-value pair.
>
> So I would like to hear your general thoughts about this method (I've 
> heard some good/bad things about it) and your specific experiences with it 
> and django (if any).
>
> I found this repository https://github.com/mvpdev/django-eav that I could 
> use as reference.
>
> Thanks!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/f0c8def8-d577-4f37-8e67-17fdae896219%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/688ac60a-ccd9-40cd-b52b-01e8dc68e523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Models not appearing in db. Am I missing something?

[Mario Gudelj]

Pgadmin3 is the bomb. Try that gui tool
On 16/12/2014 4:40 pm, "Shazwi Suwandi"  wrote:

> Hey guys,
>
> I figured it was a problem with the app I'm using for the db. I went to
> use another app and now the tables are showing. Silly me. Thanks Mario and
> David for your helpful advice. :)
>
> On Tuesday, 16 December 2014 13:33:36 UTC+8, Shazwi Suwandi wrote:
>>
>> Hey Mario,
>>
>> The output I get when I use makemigrations is
>>
>>   0001_initial.py:
>>
>> - Create model Member.
>>
>> I've double checked:
>>
>>
>>- The 'Member' model is in core/models.py
>>- 'Core' is inside project/settings.py
>>
>> I use python manage.py shell and I accessed the 'User' object and the
>> linked 'Member' object to get the fields inside and it works.
>> Furthermore, when I went to my db gui and try to delete the rows in the
>> 'auth_user' table, it says that there is a constraint in 'core_member'
>> table.
>>
>> Here's the link to the image that shows all the tables I have.
>> http://i.imgur.com/M1ZWznt.png
>>
>>
>> On Tuesday, 16 December 2014 11:18:58 UTC+8, somecallitblues wrote:
>>>
>>> What's the output of your makemigrations command? If those models are
>>> inside core/models.py and your app is inside installed apps in settings
>>> this should totally work. The default name for the table will be
>>> appname_modelname. Do you get an error when accessing the model? How are
>>> you checking the db for tables?
>>> On 15/12/2014 11:00 pm, "Shazwi Suwandi"  wrote:
>>>
 Hey David,

 You're right, I have to practise writing tests along with my codes.
 However, just to clarify, data input and output works. I can call the data
 in the Member object. I'm just confused as to why the Member table does not
 show up in my postgres database. It's weird.

 Nevertheless, I'll start writing unit tests.

 On Monday, 15 December 2014 19:03:23 UTC+8, David Palao wrote:
>
> Hello,
> From your post I understand you did not write unittests for your
> models?
> I would recommend to write some sensible tests for them and start
> tracing your problem from the failures you should get.
> Best,
>
> David
>
> 2014-12-15 8:15 GMT+01:00 Shazwi Suwandi :
> > I've added 'core' to settings.py file under INSTALLED_APPS too.
> >
> >
> > On Monday, 15 December 2014 15:10:12 UTC+8, Shazwi Suwandi wrote:
> >>
> >> from django.db import models
> >> from django.contrib.auth.models import User
> >>
> >> # CORE APPLICATION
> >> # Create your models here.
> >> class Member(models.Model):
> >> user = models.OneToOneField(User)
> >> description = models.CharField(max_length=250)
> >> date_of_birth = models.DateField()
> >> location = models.CharField(max_length=100)
> >> gender = models.CharField(max_length=15)
> >>
> >> class NewTable(models.Model):
> >> test = models.CharField(max_length=25)
> >>
> >> I've created some models and I used makemigrations and migrate. I
> went to
> >> my db and checked that only the default tables are there
> (auth_group ...
> >> django_session). I know that my connection settings are right and
> that I see
> >> new rows being added to the auth_user table when I create users in
> django
> >> admin page.
> >>
> >> Is there something that I must have missed out?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Django users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email to django-users...@googlegroups.com.
> > To post to this group, send email to django...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-users.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/django-users/7af04f16-09a8
> -458d-8857-c71694394101%40googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
  --
 You received this message because you are subscribed to the Google
 Groups "Django users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-users...@googlegroups.com.
 To post to this group, send email to django...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-users.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-users/6dff229e-34c3-4e4f-bb34-f95c43bec18f%
 40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from th

Re: Seeking for advise on usage MySQL together with MongoDB

[Cal Leeming]

Hi Tom,

Apologies for the slow answer, give me a week or so and I'll spend some
time putting a proper detailed reply/breakdown together in a new thread.

Cal

On Sat, Dec 13, 2014 at 11:12 AM, Tom Christie 
wrote:
>
> Hi Cal,
>
> > DRF has it's own problems and (again imho) does not solve the problems
> it was originally designed to fix. Attempting to build anything beyond "out
> of the box CRUD" requires hacky/unclean workarounds, with most of your time
> spent fighting against the shortcomings of DRF rather than working with it.
>
> I'm slightly at a loss to understand what set of pain points could have
> left you with that impression, but it'd be helpful to get a better idea.
>
> Perhaps some of the awkwardnesses in 2.x serializers that have been
> addressed with the 3.0 release?
> Perhaps a misunderstanding that viewsets/routers are intended to be the
> canonical way to use REST framework?
>
> The 'build anything beyond "out of the box CRUD"' comment is particularly
> surprising to me because of all the work I do in REST framework *none* of
> it is CRUD, and the design decisions in REST framework are very explicitly
> towards it being an agnostic Web API toolkit, that just *happens* to also
> have easy support if basic CRUD stuff *does* happen to be what you want. Eg:
>
> * Validation that's cleanly decoupled from Django's ORM, but that can also
> work seemlessly with it if that's what you need.
> * Works just fine with regular views, but has a minimal set of
> pre-provided generic views if simple CRUD operations are what you need.
> * Viewsets and routers for projects that fit well with a very standard URL
> style, or drop down to views and explicit URL conf otherwise.
>
> I don't want to jump on and just criticize the view point you've presented
> - whatever it is that's left you with that impression is clearly a useful
> data point for me.
>
> What other API toolkits would you look towards as more mature, well
> supported, nicely designed solutions?
> Which shortcomings were you fighting against, and what do you think the
> project should be doing differently?
>
> Cheers,
>
>   Tom
>
> On Friday, 12 December 2014 18:05:02 UTC, Cal Leeming wrote:
>>
>> Hi Collin,
>>
>> Just a few comments;
>>
>> On Fri, Dec 12, 2014 at 5:42 PM, Collin Anderson 
>> wrote:
>>>
>>> Hi,
>>>
>>> Re: the hacker news thread, (sorry for getting a little off topic,) I
>>> just wanted to mention a few places where we've tried to improve some of
>>> those things recently:
>>> - The ORM is still slow, but we've added prefetch_related() and improved
>>> select_related() which allows you do use fewer queries.
>>>
>> - We've pulled out some of components into separate projects:
>>> django-localflavor, django-contrib-comments, django-formtools, and I
>>> imagine more in the future.
>>> - You can now use custom user models.
>>>
>>
>> Custom models is (imho) still unnecessarily complex, something as simple
>> as not requiring a username field requires a lot of work. There have been
>> several instances where migrations had to be scraped due to weird edge
>> cases with custom user models.
>>
>>
>>> - We're working on an official public API for the model._meta internals
>>> and working towards components only using that. It also means it will be
>>> easier to use non-django models in the admin.
>>> - We're working on de-coupling django templates, allowing them to be
>>> used on their own, and making it much easier to use other template engines
>>> like Jinja2.
>>> - There's are also quite a lot of people using django-rest-framework for
>>> creating REST apis, which was one thing the thread said django was not good
>>> at.
>>>
>>
>> DRF has it's own problems and (again imho) does not solve the problems it
>> was originally designed to fix. Attempting to build anything beyond "out of
>> the box CRUD" requires hacky/unclean workarounds, with most of your time
>> spent fighting against the shortcomings of DRF rather than working with it.
>>
>> Building a clean RESTful API in Django is possible, but it requires a lot
>> of custom libs/hacks to make it work properly. For example, you have to
>> create your own method dispatcher/router, which in turn breaks
>> class/dispatch decorators due to the way those are loaded. Or you could
>> throw it all into a single class and split out the functionality using
>> get/post/put, but this is really unclean because each HTTP method is
>> essentially it's own view. Another way is to not use decorators of course.
>> Then you have partial form handling, which I already touched on in another
>> thread [1], so I won't repeat here.
>>
>> These are just a few examples of annoyances which hinder productivity.
>> That being said, Django is still quite good at a lot of things, and again
>> it comes down to "the right tool for the job". It's all about knowing the
>> strength/weaknesses of your options, and making an appropriate choice based
>> on your use case, making sacrifices dependant on your needs etc.
>>
>> 

Re: Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

[Shazwi Suwandi]

Do the demos on the main site work for any of you?

On Tuesday, 16 December 2014 12:22:06 UTC+8, Aaron Reabow wrote:
>
> the thing i am trying to figure out is how this works with my existing 
> setup.
>
> I get that you need to install redis. but how does the rest of the stack 
> change
>
> mine is through the good people at webfaction:
>
> apache tomcat
> nginx (static)
> postgres
> python2.7
> django1,6
> html/css/js
>
> how much of this can i leave alone, while installing redis?
>
> On Wednesday, 12 November 2014 06:37:47 UTC+2, Suren Sth wrote:
>>
>> I recently came across Swampdragon ( Visit official site 
>> ). I am curious can it be used in production 
>> sites and will it scale ? If it can be, what is the best way?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/635ee58a-a069-4a59-8772-2777103be0bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django don't load css

[Héctor Urbina]

Vadims Briksins seems to have had the same problem 
 in Django 1.6.4. You could 
contact 
him  and ask him if and how he 
resolved it.

On Monday, December 15, 2014 6:38:50 PM UTC-3, Jovana Andjelkovic wrote:
>
> Sorry,I didn't understand him :) 
> I check css with css validator and it didn't find any errors.It is simple 
> css file,just to check if everithing is working.
> I don't understand why css is not recognised as text/css,but as text/plain.
> Thank you for your answer...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b486a2ff-dc96-4c7a-947f-6e9a1a1e17ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking for advise on usage MySQL together with MongoDB

[Tom Christie]

Thanks Cal. If you do get the time that'd be fab, positive criticism is 
always useful. Equally please don't feel obligated - sure you weren't 
expecting to have to give a blow-by-blow breakdown of pain points you 
found. :p

May be worth taking any further convo over to the django-rest-framework 
list, but either forum works for me.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/12f78416-ab39-4646-a89c-286668d3fa64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django don't load css

[Jovana Andjelkovic]

Thank you,I will.I'll let you know if I solve my problem...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/96b85e25-d7d1-437a-964d-983434283921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Odd subform caching problem

[Collin Anderson]

Hi,

It's probably better to handle the default in the save() method.

def save(self, **kwargs):
if not self.id:
self.id = get_entity_id()
super(Entity, self).save(**kwargs)

Or, better yet, just remove the "id = models.BigIntegerField" line 
completely and let django give you a models.AutoField which should properly 
auto-increment.

Collin

On Monday, December 15, 2014 7:45:47 AM UTC-5, Gerald Klein wrote:
>
> if I remove the parens, when I submit to create the new entity is throws a 
> validation error that does not specify the field that is wrong, "Please 
> correct the error below."
>
> --jerry
>
> On Mon, Dec 15, 2014 at 6:20 AM, Daniel Roseman  > wrote:
>>
>> On Monday, 15 December 2014 11:04:13 UTC, Gerald Klein wrote:
>>>
>>>
>>>
>>> Daniel, 
>>> I didn't include any code as I didn't do anything unusual but if you 
>>> think that would help here it is.I was hoping that there was some ordinary 
>>> theoretical basis for this as I didn't do anything custom really, aside 
>>> from the id generation for the "Entity" class, which I generate the id 
>>> manually much like an Oracle sequence object, I do this in order to 
>>> facilitate the creation of relationships between arbitrary objects. 
>>>
>>
>> But that "aside" is of course the entire problem.
>>
>> class Entity(models.Model):
>>> """ the fName field is also the company name field """
>>> id = models.BigIntegerField(primary_key=True, unique=True, 
>>> default=get_entity_id())
>>>
>>
>> Leaving aside whatever reasons you have for doing this very odd thing, 
>> the error is clear: you've called the get_entity_id function in the 
>> definition, which means it is executed at first import time, so every 
>> instance of Entity gets the same ID as its default. If you're using a 
>> function to provide a default value, you must always pass the *callable*, 
>> like this:
>>
>> id = models.BigIntegerField(primary_key=True, unique=True, 
>> default=get_entity_id)
>>
>> ie without the calling brackets.
>>
>> But I strongly recommend you don't do this. Whatever you mean by 
>> "facilitating the creation of relationships between arbitrary objects", 
>> there is almost certainly a better way to do it in Django.
>> --
>> DR.
>>
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/312afeac-a3cf-479b-a544-7f6690732257%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> Gerald Klein DBA
>
> cont...@geraldklein.com 
>
> www.geraldklein.com 
> 
>
> geraldklein.wordpress.com 
> 
>
> j...@zognet.com 
>
> 708-599-0352 
> 
>
>
> Arch, Gentoo I3, Ranger & Vim the coding triple threat.
>
> Linux registered user #548580 
>
> Brought to you by the Amish Mafia
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5a204c8e-68f7-49f3-9326-973f89442915%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need to search through several tables using one model

[Collin Anderson]

Hi,

The new link isn't working either.

Collin

On Monday, December 15, 2014 8:45:10 AM UTC-5, Damjan Dimitrioski wrote:
>
> Oh, sorry about that, it was se to an hour, here is an updated one: 
> https://dpaste.de/q9sq
>
> On Mon, Dec 15, 2014 at 2:13 PM, Vijay Khemlani  > wrote:
>>
>> The dpaste link is broken
>>
>> On Mon, Dec 15, 2014 at 9:48 AM, Damjan Dimitrioski <
>> damjandi...@gmail.com > wrote:
>>
>>> I wrapped something like this:
>>> https://dpaste.de/4WTq
>>>
>>> However, I'm not able to see any results in the changelist view, but the 
>>> get_query_set method prints the query results in the STDOUT, what I'm doing 
>>> wrong ?
>>>
>>> On Sat, Dec 13, 2014 at 11:27 PM, Damjan Dimitrioski <
>>> damjandi...@gmail.com > wrote:

 The search filter above the change list view template, there is a 
 button named search I think, I think it's need to overriden in order to 
 implement custom model or something.

 On Sat, Dec 13, 2014 at 11:06 PM, Vijay Khemlani >>> > wrote:
>
> What search button are you talking about?
>
> On Sat, Dec 13, 2014 at 2:23 PM, Alon Nisser  > wrote:
>>
>> You could also create a model that foreign keys to all the relevant 
>> models, and filter on that.. 
>> Buy first you need to clarify (for your self..) The exact use case: 
>> is it search? if so better use haystack with some search backend 
>> (elasticsearch would be a great choice), Is it to choose something in a 
>> form? something else? 
>>
>> The technical details should be derived from the problem you are 
>> trying to solve.. 
>>
>> On Friday, December 12, 2014 5:09:30 PM UTC+2, Damjan Dimitrioski 
>> wrote:
>>>
>>> Hi,
>>>
>>> Is there a way to make a model that links several db tables in one 
>>> model, so that can be used in a change list view ?
>>> Most importantly, I need to be able to use the search field, can 
>>> this be accomplished ?
>>>
>>> Regards.
>>>
>>  -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/235267f4-1851-4464-9426-b63dc074d671%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>  -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-users/oaInfa9o4Js/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to 
> django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CALn3ei0RSv4RuAyp%2BBhk5c9Qi4riF%3DFF3VXVQ_cr1rnuAxBs2g%40mail.gmail.com
>  
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-users...@googlegroups.com .
>>> To post to this group, send email to django...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/CAHDCi6Rx%2BLzfsykLzBNB1RZV-7Zjg%3DowZ_yZoR4RNOZC0skQ3w%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-users/oaInfa9o4Js/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> django-users...@googlegroups.com .
>> To post to this group, send email to django...@google

control attributes on form fields in formset

[Brad Rice]

When I do a model form I can control the fields with attributes using 

name = 
forms.CharField(widget=forms.TextInput(attrs={'class':'u-full-width'}))

How do I do something like that in an inline formset? I don't see where I 
can set attributes.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f549611e-986f-43c9-b229-3ea7360669b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Questions about code reviews and static analysis tools for TU Delft research

[Radjino Bholanath]

 

Hi everyone, 

I'm doing research on code reviews and static analysis tools at the SERG 
group  of the Delft 
University of Technology. Currently, we want to give an overview of the 
usage of code review and static analysis tools in open source projects. 
Therefore, I would be very happy to know a little bit more about how code 
reviews are used in Django and if (and maybe how) static analysis tools are 
used. I have a couple of questions for anyone willing to answer:

1.   1. Do all developers (contributors and core developers) have to 
submit a code review for every change? I’m asking because many projects 
only review changes made by contributors.

2.   2. Which code review tools are used (just Github, or maybe other 
tools)?

3.   3. Are static analyzers used? If they are used:

a.   Is passing the checks of the static analyzers necessary for a 
change to be accepted?

b.  Which static analyzers are used?

Thanks,

Radjino

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9a60fa8b-bd38-4a8e-91e4-89293f3353dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7: How to migrate data between two external apps

[Markus Holtermann]

Hey John-Scott,

I'm afraid but I don't see an obvious solution. There are 2 ways you could 
work on the issue, I don't like either:

1. remove all references to the "foo_tag" app from all migration files

2. make use of the MIGRATION_MODULES settings:

2.1. create a package "path.to.foo_tag_legacy"
2.2. inside create an empty migration "0001_initial"
2.3. define MIGRATION_MODULES={"foo_tag": "path.to.foo_tag_legacy"}

As said, both seem ugly to me. I don't know which way I'd proceed.

You might get it working by squashing migrations, but certainly not without 
manually writing those migration files.

/Markus

On Saturday, December 13, 2014 6:26:17 PM UTC+1, John-Scott wrote:
>
> Say I decided to switch from a third party app foo-tags to app bar-tags. 
> Their Tag models are mostly identical so I just need to move the data from 
> foo-tag to bar-tag. Since I don't control their migrations, I'd need to 
> create a migration in one of my own apps:
>
> ./manage.py makemigrations my_app --empty
>
> In this migration I'd need to explicitly list the dependencies on these 
> external apps (otherwise was getting errors that the foo and bar apps were 
> not available in the app registry):
>
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models, migrations
>
> def migrate_tags(apps, schema_editor):
> FooTag = apps.get_model('foo_tag', 'FooTag')
> BarTag = apps.get_model('bar_tag', 'BarTag')
> for old_tag in FooTag.objects.all():
> new_tag = BarTag.objects.create(name=old_tag.name)
>
> class Migration(migrations.Migration):
> dependencies = [
> ('my_app', '0001_initial'),
> ('foo_tag', '0001_initial'),
> ('bar_tag', '0001_initial'),
> ]
>
> operations = [
> migrations.RunPython(migrate_tags)
> ]
>
>
> The migration itself works as expected. However if I now remove foo_tag 
> from INSTALLED_APPS, Django will now give an error:
>
> KeyError: "Migration my_app.0002_auto_20141212_1951 dependencies 
> reference nonexistent parent node ('foo_tag', '0001_initial')"
>
> What's the correct way to handle migrating data between 3rd party apps 
> where one of the apps is eventually removed?
>
> Thanks,
> John-Scott
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/79ab531b-da9c-46b8-ba03-11afeb6906d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: InMemoryUploadedFile object retrieved from request.FILES got closed automatically on django 1.7

[Hong Yi]

Many thanks for the detailed explanation, Russ! Really appreciate it. Now I 
understand much better why django 1.7 enforces this. I will follow your 
advice to re-structure my code to make it work on django 1.7.

Best regards,
Hong

On Monday, December 15, 2014 6:55:04 PM UTC-5, Russell Keith-Magee wrote:
>
>
> On Tue, Dec 16, 2014 at 4:53 AM, Hong Yi > 
> wrote:
>
>> Hello,
>>
>> I am new to Django and have implemented two views and their corresponding 
>> template pages and they are working well in Django 1.6. However, when 
>> migrating to Django 1.7, I got an error "I/O operation on closed file" when 
>> getting to the second view function. I found out the root cause for this 
>> error is that on Django 1.7, InMemoryUploadedFile object retrieved from 
>> request.FILES got automatically closed at the end of the request by Django. 
>> I am trying to find a solution to work around this migration issue. 
>> Specifically, the first view and its template page ask users to browse 
>> files, and the files can be retrieved from request.FILES and saved to a 
>> global variable for use by the second view/request. Since the file got 
>> closed automatically at the end of the first request, when the second view 
>> tries to operate on this file, that "I/O operation on closed file" error 
>> results. 
>>
>> This is my first post, and I am trying to get some 
>> recommendations/suggestions on how to handle this use case to work around 
>> this new security feature implemented in Django 1.7 (i.e., automatically 
>> close file at the end of each request). Any help and suggestions are 
>> greatly appreciated.
>>
>>
> Hi Hong,
>
> In this case, the solution isn't to work around Django - it's to work out 
> why Django is getting in your way. The cause is a fundamental 
> misunderstanding about how you should be looking at the web. 
>
> Each request on a web site should be completely independent - you can't 
> rely on shared state between one request and the "next" request. Two 
> examples for why this is important:
>
> 1) The second request might be served by an entirely different server. 
> Once you get into any sort of non-trivial deployment, you will have more 
> than one web server to ensure availability; if a file has been uploaded on 
> one server, it won't be available on the other server unless you're 
> providing some sort of independent storage.
>
> 2) There's no guarantees that a single user will be responsible for two 
> requests in a row. It's easy to think of a situation where there are two 
> users using your website at the same time; if your website code makes any 
> assumptions about request ordering, it makes a big difference whether the 
> requests are handled as AABB or ABAB. If A and B are normal users, this 
> might just be an annoying bug; if B is an attacker, then A's data could be 
> stolen or compromised. 
>
> You might claim that your website will never be big enough to require (1), 
> or have enough users that (2) will be a problem - and that might be true - 
> but it doesn't change the fact that web frameworks are built on the 
> assumption that both (1) and (2) are going to happen, and the 
> infrastructure they put in place will ensure that those two cases don't 
> cause problems.
>
> So - you shouldn't be using a global variable to store *anything*. (That's 
> generally good advice for programming anyway, but it's doubly important for 
> web programming). You also shouldn't be loading data into memory on the 
> assumption that it will be used in the "next" request. If I were an 
> attacker, and I found out that you were doing this, I would make a whole 
> stack of the first requests, and then never make the second request - and 
> I've just starved your server of memory.
>
> If you need to have a 2 step process where one view selects a file, and 
> the second view "handles" the file, then what you should be passing around 
> is a filename, or some other reference that lets you retrieve a file. Then, 
> the two views should be built so that they are completely independent. View 
> 1 provides a way for a user to select a file. View 2 opens, reads, 
> processes and closes the file.
>
> Memory usage shouldn't be a concern here. When you open a file, you don't 
> have to load the whole thing into memory to pass it around. Operating 
> systems are really good at handling file pointers, which are just an index 
> into an open file. You don't have to store any more data than the character 
> you're currently pointing at. Most file formats are developed so that you 
> don't need to read the *entire* file into memory in one pass - they're 
> optimised to allow you to read them "on demand". 
>
> In short - don't work around this problem; fix the underlying cause of the 
> problem, and restructure your app.
>
> Hope this has been helpful!
>
> Yours
> Russ Magee %-)
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this gr

ANN: Django website redesign launched

[Jannis Leidel]

Hi everyone,

We're incredibly proud to share with you the new design of the Django website, 
the documentation and the issue tracker.

This is a long time coming and we couldn't be happier to finally ship it :)

As you can imagine, there will be bugs, so please bear with us and report 
issues to the issue tracker at 
https://github.com/django/djangoproject.com/issues

More infos about the redesign and its history can be found in the blog post:

  
https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/

Happy coding, everyone!

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ANN: Django website redesign launched

[Fred Stluka]

Jannis,

Care to summarize what has changed?  At first glance, it looks like
mostly the same excellent content and the same sensible
organization of info, with the same useful mechanisms like the
ability to easily flip between different versions of the docs.

Are the changes mostly to do with CSS styles, colors, fonts,
presentation of info?  Or is there a change to the content or the
navigation, as well?

Thanks!
--Fred

Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

On 12/16/14 11:09 AM, Jannis Leidel wrote:

Hi everyone,

We're incredibly proud to share with you the new design of the Django website, 
the documentation and the issue tracker.

This is a long time coming and we couldn't be happier to finally ship it :)

As you can imagine, there will be bugs, so please bear with us and report 
issues to the issue tracker at 
https://github.com/django/djangoproject.com/issues

More infos about the redesign and its history can be found in the blog post:

   
https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/

Happy coding, everyone!

Jannis



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54905B00.9070908%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Jose Regalado]

NIce!.

2014-12-16 11:39 GMT-04:30 Jannis Leidel :
> Hi everyone,
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker.
>
> This is a long time coming and we couldn't be happier to finally ship it :)
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues
>
> More infos about the redesign and its history can be found in the blog post:
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>
> Happy coding, everyone!
>
> Jannis
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
José Luis Regalado
bashman
Linux User nº 280381
WhatsApp / Telegram  +58 416 1705119

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAG7DY1jEcYohLxecTGeok1530%2B-B-nt4P%2BDHjm3dpXZ7bGjghw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django don't load css

[Jovana Andjelkovic]

Thank you very much,Vadims helped me.
The problem wasn't related to the Django,I installed NuSphere and it 
changed values in os registry.
In regedit.exe I changed all css to text/css,restarted PC and css is now 
working fine...
Here is registry fix,if someone who is having this type of problem don't 
want to change registry manualy:
http://community.skype.com/t5/Windows-desktop-client/Skype-6-10-0-104-BIG-Login-screen-problem/m-p/2104915/highlight/true#M202212
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54632d50-0b80-47f3-9ad0-44bc2ad58650%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Carol Willing]

Thanks to all that made this happen. Much more user friendly. Bravo!

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/24df9e84-151d-4f8b-ade9-95fcd4c945aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Tim Chase]

> As you can imagine, there will be bugs, so please bear with us and
> report issues to the issue tracker at
> https://github.com/django/djangoproject.com/issues

I appreciate the clarification/distinction between Django-Users and
Django-Developers mailing-lists.  I don't remember them being this
blatant before.

I did notice that, if remote-font-loading is disabled, certain icons
don't come out intelligently.  To demonstrate what would happen if
the font-file was unavailable, you can use Firefox, go to about:config
and set "browser.display.use_document_fonts" to 0.

If the icons were mapped into spots that correspond to an actual
Unicode for something similar, they'd show up even if the fonts don't
load as long as the local font supports that code-point.  Examples:

- The envelope in the mailing-list sign-up boxes appears locally as a
  digital/8-segment-display "20". Unicode has an icon-designation for
  an envelope: "\N{ENVELOPE}" (U+2709).

- the "new page" icon that is used along the right side-bar could be
  "\N{PAGE FACING UP}" (U+1F4C4), "\N{DOCUMENT}" (U+1F5CE), or
  "\N{PAGE}" (U+1F5CF)

- the megaphone by the "Read More" could be mapped into "\N{CHEERING
  MEGAPHONE}" (U+1F4E3), "\N{BULLHORN}" (U+1F56B), or "\N{BULLHORN
  WITH SOUND WAVES}" (U+1F56C).

- The three icons on the main page (lightning bold, lock, speedometer)
  at least two could use "\N{LIGHTNING MOOD}" (U+1F5F2) and
  "\N{LOCK}" (U+1F512). I wasn't able to come up with something in
  stock Unicode to signify scaling except possibly "\N{WORLD
  MAP}" (U+1F5FA)

- on the /start/ page, there are some plus-signs that would render if
  "\N{HEAVY PLUS SIGN}" (U+2795) was used instead. (I did notice that
  this page works well even if JS is disabled. Major kudos there!)

Based on the underlying CSS, it looks like there might be a lot more
than just the ones I discovered in the first 5min of reading.  I tend
to discover these font issues since I generally fly with the above FF
setting configured because some sites choose fonts that are hard for
me to read.  Disabling remote fonts solves that for me (FF doesn't
offer a more granular permission for font-loading, AFAIK).

They're not a major concern, but a nice-to-have.  I can paste this
into a Github issue if you want to track it there.

-tkc

Links to the Unicode icons if you want examples:
http://www.fileformat.info/info/unicode/char/2709/index.htm
http://www.fileformat.info/info/unicode/char/2795/index.htm
http://www.fileformat.info/info/unicode/char/1F4C4/index.htm
http://www.fileformat.info/info/unicode/char/1F4E3/index.htm
http://www.fileformat.info/info/unicode/char/1F512/index.htm
http://www.fileformat.info/info/unicode/char/1F56B/index.htm
http://www.fileformat.info/info/unicode/char/1F56C/index.htm
http://www.fileformat.info/info/unicode/char/1F5CE/index.htm
http://www.fileformat.info/info/unicode/char/1F5CF/index.htm
http://www.fileformat.info/info/unicode/char/1F5F2/index.htm
http://www.fileformat.info/info/unicode/char/1F5FA/index.htm


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20141216113755.3485d179%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Tom Evans]

Good work, it looks a lot cleaner.

However:

In the documentation, the page title "Documentation" always used to
link back to the index page for the current documentation version. Now
it appears there is only a link in the "You are here" section of the
sidebar?

The cleaner look makes much less information visible on a page,
particularly on small screens. For instance, on my laptop screen
(1280x800), on part 4 of the tutorial in the documentation, the fold
now is at the "{% if error_message %}" in the first code block, where
as in the old style the entire code block and the subsequent paragraph
is visible. Similarly, on the index page, the only part of the index
visible above the fold is "First steps".

On a related note, the larger font and increased spacing also means
that the line length before wrapping is reduced. The maximum line
length in a code block in the documentation is around 73 characters,
compared to around 97 characters in the old style. Several lines in
the code block in the new page wrap, whilst in the old style none did
(I suspect the code blocks were originally written so that they would
not need to wrap with the old style).

I'm no style guru, but is the CSS styling of selected text necessary
for the design to work? I found it surprising - my initial thought was
"grrr, why can't I select any text", as the pastel blue is very washed
out on my cheap work panel and I found it difficult to notice that any
text is selected.

FYI, I am comparing these pages:

https://docs.djangoproject.com/en/1.7/intro/tutorial04/

https://web.archive.org/web/20140802064954/https://docs.djangoproject.com/en/1.7/intro/tutorial04/

Apart from these minor things, looks really good!

Cheers

Tom

On Tue, Dec 16, 2014 at 4:09 PM, Jannis Leidel  wrote:
> Hi everyone,
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker.
>
> This is a long time coming and we couldn't be happier to finally ship it :)
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues
>
> More infos about the redesign and its history can be found in the blog post:
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>
> Happy coding, everyone!
>
> Jannis
>
> --
> 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-develop...@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/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1Jovo08%3D%2B2rpbPYhOdi5vkDzk_CGx6prxs%2BzpJRmEcDOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Ari Davidow]

>On a related note, the larger font and increased spacing also means
>that the line length before wrapping is reduced. The maximum line
>length in a code block in the documentation is around 73 characters,
>compared to around 97 characters in the old style.

Since, at text sizes, the eye can track about 65 characters in a line, the
change is good, and welcome. About 20 years ago, having heard this claim
from typographers for many years, we tested on some web pages. We'd have
the volunteers read something that was set as wide as the screen, then at
other dimensions narrowing to about 40 characters. Sure enough, once the
lines were wider than 60-70 characters, on average, we'd ask people what
they thought about "X" and we'd as often as not get the response, "Oh, 'X'
isn't on this page."

Given indentation, this isn't always a python issue, but it is worth
bearing in mind.

ari

On Tue, Dec 16, 2014 at 1:07 PM, Tom Evans  wrote:
>
> Good work, it looks a lot cleaner.
>
> However:
>
> In the documentation, the page title "Documentation" always used to
> link back to the index page for the current documentation version. Now
> it appears there is only a link in the "You are here" section of the
> sidebar?
>
> The cleaner look makes much less information visible on a page,
> particularly on small screens. For instance, on my laptop screen
> (1280x800), on part 4 of the tutorial in the documentation, the fold
> now is at the "{% if error_message %}" in the first code block, where
> as in the old style the entire code block and the subsequent paragraph
> is visible. Similarly, on the index page, the only part of the index
> visible above the fold is "First steps".
>
> On a related note, the larger font and increased spacing also means
> that the line length before wrapping is reduced. The maximum line
> length in a code block in the documentation is around 73 characters,
> compared to around 97 characters in the old style. Several lines in
> the code block in the new page wrap, whilst in the old style none did
> (I suspect the code blocks were originally written so that they would
> not need to wrap with the old style).
>
> I'm no style guru, but is the CSS styling of selected text necessary
> for the design to work? I found it surprising - my initial thought was
> "grrr, why can't I select any text", as the pastel blue is very washed
> out on my cheap work panel and I found it difficult to notice that any
> text is selected.
>
> FYI, I am comparing these pages:
>
> https://docs.djangoproject.com/en/1.7/intro/tutorial04/
>
>
> https://web.archive.org/web/20140802064954/https://docs.djangoproject.com/en/1.7/intro/tutorial04/
>
> Apart from these minor things, looks really good!
>
> Cheers
>
> Tom
>
> On Tue, Dec 16, 2014 at 4:09 PM, Jannis Leidel  wrote:
> > Hi everyone,
> >
> > We're incredibly proud to share with you the new design of the Django
> website, the documentation and the issue tracker.
> >
> > This is a long time coming and we couldn't be happier to finally ship it
> :)
> >
> > As you can imagine, there will be bugs, so please bear with us and
> report issues to the issue tracker at
> https://github.com/django/djangoproject.com/issues
> >
> > More infos about the redesign and its history can be found in the blog
> post:
> >
> >
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
> >
> > Happy coding, everyone!
> >
> > Jannis
> >
> > --
> > 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-develop...@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/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAFHbX1Jovo08%3D%2B2rpbPYhOdi5vkDzk_CGx6prxs%2BzpJRmEcDOg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this g

Re: ANN: Django website redesign launched

[Jannis Leidel]

> On 16 Dec 2014, at 17:17, Fred Stluka  wrote:
> 
> Jannis,
> 
> Care to summarize what has changed?  At first glance, it looks like
> mostly the same excellent content and the same sensible 
> organization of info, with the same useful mechanisms like the 
> ability to easily flip between different versions of the docs.

Yeah, the content hasn't changed much, so you can think about this change as a 
new skin to make it look less outdated than before. We're also now using 
techniques like a responsive layout to cater to the current growing mobile web 
audience.

> Are the changes mostly to do with CSS styles, colors, fonts, 
> presentation of info?  Or is there a change to the content or the 
> navigation, as well?

All links should continue to work, and if not then it's a bug. We do have a new 
/start/ page that has some more info. More coming soon :)

Jannis

> Thanks!
> --Fred
> Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates.
> On 12/16/14 11:09 AM, Jannis Leidel wrote:
>> Hi everyone,
>> 
>> We're incredibly proud to share with you the new design of the Django 
>> website, the documentation and the issue tracker.
>> 
>> This is a long time coming and we couldn't be happier to finally ship it :)
>> 
>> As you can imagine, there will be bugs, so please bear with us and report 
>> issues to the issue tracker at 
>> https://github.com/django/djangoproject.com/issues
>> 
>> 
>> More infos about the redesign and its history can be found in the blog post:
>> 
>>   
>> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>> 
>> 
>> Happy coding, everyone!
>> 
>> Jannis
>> 
>> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/54905B00.9070908%40bristle.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3F841881-8B3A-4BB4-8332-4B98FA16520B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Jannis Leidel]

> On 16 Dec 2014, at 18:37, Tim Chase  wrote:
> 
>> As you can imagine, there will be bugs, so please bear with us and
>> report issues to the issue tracker at
>> https://github.com/django/djangoproject.com/issues
> 
> I appreciate the clarification/distinction between Django-Users and
> Django-Developers mailing-lists.  I don't remember them being this
> blatant before.
> 
> I did notice that, if remote-font-loading is disabled, certain icons
> don't come out intelligently.  To demonstrate what would happen if
> the font-file was unavailable, you can use Firefox, go to about:config
> and set "browser.display.use_document_fonts" to 0.
> 
> If the icons were mapped into spots that correspond to an actual
> Unicode for something similar, they'd show up even if the fonts don't
> load as long as the local font supports that code-point.  Examples:
> 
> - The envelope in the mailing-list sign-up boxes appears locally as a
>  digital/8-segment-display "20". Unicode has an icon-designation for
>  an envelope: "\N{ENVELOPE}" (U+2709).
> 
> - the "new page" icon that is used along the right side-bar could be
>  "\N{PAGE FACING UP}" (U+1F4C4), "\N{DOCUMENT}" (U+1F5CE), or
>  "\N{PAGE}" (U+1F5CF)
> 
> - the megaphone by the "Read More" could be mapped into "\N{CHEERING
>  MEGAPHONE}" (U+1F4E3), "\N{BULLHORN}" (U+1F56B), or "\N{BULLHORN
>  WITH SOUND WAVES}" (U+1F56C).
> 
> - The three icons on the main page (lightning bold, lock, speedometer)
>  at least two could use "\N{LIGHTNING MOOD}" (U+1F5F2) and
>  "\N{LOCK}" (U+1F512). I wasn't able to come up with something in
>  stock Unicode to signify scaling except possibly "\N{WORLD
>  MAP}" (U+1F5FA)
> 
> - on the /start/ page, there are some plus-signs that would render if
>  "\N{HEAVY PLUS SIGN}" (U+2795) was used instead. (I did notice that
>  this page works well even if JS is disabled. Major kudos there!)
> 
> Based on the underlying CSS, it looks like there might be a lot more
> than just the ones I discovered in the first 5min of reading.  I tend
> to discover these font issues since I generally fly with the above FF
> setting configured because some sites choose fonts that are hard for
> me to read.  Disabling remote fonts solves that for me (FF doesn't
> offer a more granular permission for font-loading, AFAIK).
> 
> They're not a major concern, but a nice-to-have.  I can paste this
> into a Github issue if you want to track it there.

Yes, that would be really appreciated. Part of our upcoming work is to improve 
accessibility issues like this. A ticket on the GitHub issue tracker 
(https://github.com/django/djangoproject.com/issues) would be a great start to 
collect those infos.

Thanks!

Jannis

> Links to the Unicode icons if you want examples:
> http://www.fileformat.info/info/unicode/char/2709/index.htm
> http://www.fileformat.info/info/unicode/char/2795/index.htm
> http://www.fileformat.info/info/unicode/char/1F4C4/index.htm
> http://www.fileformat.info/info/unicode/char/1F4E3/index.htm
> http://www.fileformat.info/info/unicode/char/1F512/index.htm
> http://www.fileformat.info/info/unicode/char/1F56B/index.htm
> http://www.fileformat.info/info/unicode/char/1F56C/index.htm
> http://www.fileformat.info/info/unicode/char/1F5CE/index.htm
> http://www.fileformat.info/info/unicode/char/1F5CF/index.htm
> http://www.fileformat.info/info/unicode/char/1F5F2/index.htm
> http://www.fileformat.info/info/unicode/char/1F5FA/index.htm
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/20141216113755.3485d179%40bigbox.christie.dr.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/C96FD24D-87A2-467C-883E-1FA9080E25AD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Jannis Leidel]

> On 16 Dec 2014, at 19:07, Tom Evans  wrote:
> 
> Good work, it looks a lot cleaner.
> 
> However:
> 
> In the documentation, the page title "Documentation" always used to
> link back to the index page for the current documentation version. Now
> it appears there is only a link in the "You are here" section of the
> sidebar?

Good catch, mind opening a ticket for that?

> The cleaner look makes much less information visible on a page,
> particularly on small screens. For instance, on my laptop screen
> (1280x800), on part 4 of the tutorial in the documentation, the fold
> now is at the "{% if error_message %}" in the first code block, where
> as in the old style the entire code block and the subsequent paragraph
> is visible. Similarly, on the index page, the only part of the index
> visible above the fold is "First steps".

Fixed in https://github.com/django/djangoproject.com/pull/186

> On a related note, the larger font and increased spacing also means
> that the line length before wrapping is reduced. The maximum line
> length in a code block in the documentation is around 73 characters,
> compared to around 97 characters in the old style. Several lines in
> the code block in the new page wrap, whilst in the old style none did
> (I suspect the code blocks were originally written so that they would
> not need to wrap with the old style).

Hmm, that may require a new ticket, especially if it turns out that we have to 
fix the rST files in the docs. Can you open a ticket with the examples you 
mention?

> I'm no style guru, but is the CSS styling of selected text necessary
> for the design to work? I found it surprising - my initial thought was
> "grrr, why can't I select any text", as the pastel blue is very washed
> out on my cheap work panel and I found it difficult to notice that any
> text is selected.

Fixed in https://github.com/django/djangoproject.com/pull/192

> FYI, I am comparing these pages:
> 
> https://docs.djangoproject.com/en/1.7/intro/tutorial04/
> 
> https://web.archive.org/web/20140802064954/https://docs.djangoproject.com/en/1.7/intro/tutorial04/
> 
> Apart from these minor things, looks really good!
> 
> Cheers
> 
> Tom
> 
> On Tue, Dec 16, 2014 at 4:09 PM, Jannis Leidel  wrote:
>> Hi everyone,
>> 
>> We're incredibly proud to share with you the new design of the Django 
>> website, the documentation and the issue tracker.
>> 
>> This is a long time coming and we couldn't be happier to finally ship it :)
>> 
>> As you can imagine, there will be bugs, so please bear with us and report 
>> issues to the issue tracker at 
>> https://github.com/django/djangoproject.com/issues
>> 
>> More infos about the redesign and its history can be found in the blog post:
>> 
>>  
>> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>> 
>> Happy coding, everyone!
>> 
>> Jannis
>> 
>> --
>> 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-develop...@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/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAFHbX1Jovo08%3D%2B2rpbPYhOdi5vkDzk_CGx6prxs%2BzpJRmEcDOg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/AE6F22E7-35EB-4BF3-B6C6-E875335D2F2F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: control attributes on form fields in formset

[Brad Rice]

Ah, found it on the django read the docs site. This is what I did in my 
inline formset factory

BookFormset = inlineformset_factory(Author, Book, extra=3, max_num=3, 
widgets={'name': forms.TextInput(attrs={'class':'u-full-width'})})

On Tuesday, December 16, 2014 8:34:25 AM UTC-5, Brad Rice wrote:
>
> When I do a model form I can control the fields with attributes using 
>
> name = 
> forms.CharField(widget=forms.TextInput(attrs={'class':'u-full-width'}))
>
> How do I do something like that in an inline formset? I don't see where I 
> can set attributes.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/78efe089-edd2-44f5-9da3-563af3cd1eba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about code reviews and static analysis tools for TU Delft research

[Tim Graham]

Hi Radjino,

1.   1. Do all developers (contributors and core developers) have to 
> submit a code review for every change? I’m asking because many projects 
> only review changes made by contributors.
>
While there is nothing that prevents core developers from committing a 
patch without review, we highly discourage that for any non-trivial change. 
Most core developers do follow the same process of submitting a pull 
request in order to get their contributions reviewed.
 

> 2.   2. Which code review tools are used (just Github, or maybe other 
> tools)?
>
GitHub is the primary review tool. We also allow attaching patches to Trac 
tickets, but it's more difficult to give substantial review comments so 
this is typically only used for trivial changes.
 

> 3.   3. Are static analyzers used? If they are used:
>
> a.   Is passing the checks of the static analyzers necessary for a 
> change to be accepted?
>
> b.  Which static analyzers are used?
>
Yes, we use flake8. It runs as part of the build process when we run a pull 
request against our continuous integration servers (Jenkins).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0e48ba08-5af7-4b9b-9705-53eaa8736e69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Content using {% include %} not appearing on detailed page Django

[Andrew Nguyen]

I'm having some problems getting some of my content to appear on my 
detailed page view, which I have in two separate html files that are being 
pulled in using {% include %}. Inside my two files, slider.htmland 
sidebar.html, I'm using tags like {{article.title}} to grab specific 
information I need about an article. 

*TRIED: *
- Changing syntax in the two included files to {{object.title}} did not 
work.

- I've tried doing {% include "sidebar.html" article=object %} in my 
detailed.html and it did not work. Instead, I would get an error 
TemplateSyntaxError 
at /gone-home Unknown argument for u'include' tag: u'article=object'.

- Also tried doing `{% include "sidebar.html" with article=object %} did 
not work either.

*detailed.html*

{% include "sidebar.html" %}

{{object.title}}
{{object.pubDate|date:"l, F j, Y" }} | {{object.author}}




{{object.body|linebreaks}}



{% include "slider.html" %}


*slider.html*





{{article.title}}




*sidebar.html*


{% for article in object_list|slice:":5" %}




{{article.title|truncatewords:"4"}}

{% endfor %}


*models.py*

from django.db import modelsfrom django.core.urlresolvers import reverse
# Create your models here.class FullArticleQuerySet(models.QuerySet):
def published(self):
return self.filter(publish=True)
class FullArticle(models.Model):
title = models.CharField(max_length=150)
author = models.CharField(max_length=150)
slug = models.SlugField(max_length=200, unique=True)
pubDate = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
category = models.CharField(max_length=150)
# gameRank = models.PositiveSmallIntegerField(default=0)
heroImage = models.CharField(max_length=250, blank=True)
relatedImage =  models.CharField(max_length=250, blank=True)
body =  models.TextField()
publish = models.BooleanField(default=True)

objects = FullArticleQuerySet.as_manager()

def __str__(self):
return self.title

def get_absolute_url(self):
return reverse("FullArticle_detailed", kwargs={"slug": self.slug})

def random(self):
return 
self.get_queryset().order_by('?').values('title','author','heroImage','body').first()

class Meta:
verbose_name = "Blog entry"
verbose_name_plural = "Blog Entries"
ordering = ["-pubDate"]

*views.py*

from django.views import genericfrom . import models 
# Create your views here.class BlogIndex(generic.ListView):
queryset = models.FullArticle.objects.published()
template_name = "list.html"
# paginate_by = 2
class BlogDetail(generic.DetailView):
model = models.FullArticle
template_name = "detailed.html"

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/343cde15-36ab-4432-836b-5947922e48b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

[Aaron Reabow]

Work on his site (yes)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f664ce13-cdf2-4221-9138-22985a187978%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Devils advocate question

[Sayth Renshaw]

With django what benefit do I get for the extra build time over Drupal or 
Rails. Configuration I assume but real world benefits not my/our joy of 
configuration. 

Why hasn't a cms been designed off django or python? A language cultural effect 
yoy would think python would be more stable than php/drupal.


Sayth

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a4c22366-0f9d-417c-8d09-5a0501f2f964%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Avraham Serour]

What extra build time?

you mean like https://www.django-cms.org/en/ or http://mezzanine.jupo.org/ ?

On Tue, Dec 16, 2014 at 11:15 PM, Sayth Renshaw 
wrote:
>
> With django what benefit do I get for the extra build time over Drupal or
> Rails. Configuration I assume but real world benefits not my/our joy of
> configuration.
>
> Why hasn't a cms been designed off django or python? A language cultural
> effect yoy would think python would be more stable than php/drupal.
>
>
> Sayth
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/a4c22366-0f9d-417c-8d09-5a0501f2f964%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tJaSfQ8nDpDQ4PmrdH%3DGFc_m-2fZaJ9mZazaTFA15oDqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CSRF Failing after server upgrade.

[Ed Rahn]

Hello,
I get CSRF 403 errors intermittently while logging in. If I remove just the 
cookies for the site, it doesn't fix it. If I remove all the cookies on the 
browser or start in an incognito mode tab it works. Also some first time 
users get the error
Only my clients seem to be getting this, I have not been able to reproduce 
it locally.

This started happening after I upgraded from Ubuntu 14.04 to 14.10.

Can anyone help me debug this?

thanks
Ed


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/cfcc3ed3-3d71-488b-9f8e-7f69ecf73997%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Tim Chase]

On 2014-12-16 13:15, Sayth Renshaw wrote:
> With django what benefit do I get for the extra build time over
> Drupal or Rails. Configuration I assume but real world benefits not
> my/our joy of configuration. 

You're asking about two separate products.

Over Rails, the feature-sets are fairly even, so it's mostly a matter
of language preference.  Some folks prefer Ruby and thus choose
Rails, while I prefer Python so I choose Django.

Regarding Drupal, that's a CMS.  You can shoehorn it into
providing other features, but it will always carry those CMS biases
with it.  While you can make your own bespoke CMS in Django (or, as
Avraham wrote, use one of many pre-existing projects).  I'd much
rather make a domain-specific application in Django than try to
hammer Drupal to my will (omitting the fact that any significant
changes in Drupal require using PHP is an instant turn-off for me).

One of Drupal's biggest advantages is the same as for any PHP
project: deployment.  For PHP projects, deployment can be done on
free or very cheap hosting services (under $5 (USD) per month)
and usually just involves dumping a bunch of files on a server via
ftp/ssh/scp/sftp or a web interface.  For Django, it requires a lot
more configuration with mod_wsgi/wsgi/uwsgi/gunicorn/fastcgi/mod_python
and a server that lets you have such long-running processes.

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20141216154116.7d40630a%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Brad Rice]

I noticed today when I went in to look something up. I like it.

On Tuesday, December 16, 2014 11:12:54 AM UTC-5, Jannis Leidel wrote:
>
> Hi everyone, 
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker. 
>
> This is a long time coming and we couldn't be happier to finally ship it 
> :) 
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues 
>
> More infos about the redesign and its history can be found in the blog 
> post: 
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>  
>
> Happy coding, everyone! 
>
> Jannis 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4a4c04ca-8e57-4351-8f1b-be30e920d64a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about code reviews and static analysis tools for TU Delft research

[Radjino Bholanath]

Thanks for answering Tim, I appreciate it.

On Tuesday, December 16, 2014 8:44:32 PM UTC+1, Tim Graham wrote:
>
> Hi Radjino,
>
> 1.   1. Do all developers (contributors and core developers) have to 
>> submit a code review for every change? I’m asking because many projects 
>> only review changes made by contributors.
>>
> While there is nothing that prevents core developers from committing a 
> patch without review, we highly discourage that for any non-trivial change. 
> Most core developers do follow the same process of submitting a pull 
> request in order to get their contributions reviewed.
>  
>
>> 2.   2. Which code review tools are used (just Github, or maybe 
>> other tools)?
>>
> GitHub is the primary review tool. We also allow attaching patches to Trac 
> tickets, but it's more difficult to give substantial review comments so 
> this is typically only used for trivial changes.
>  
>
>> 3.   3. Are static analyzers used? If they are used:
>>
>> a.   Is passing the checks of the static analyzers necessary for a 
>> change to be accepted?
>>
>> b.  Which static analyzers are used?
>>
> Yes, we use flake8. It runs as part of the build process when we run a 
> pull request against our continuous integration servers (Jenkins).
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b3a4a647-1d92-4bbd-805d-fc33c06a015a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Schmitt, Christian]

Somehow I hate it. The website is the worst website I've seen since a long
time.
The contrast is really aweful.
The issue Tracker got unusable due to the colors that aren't focused on
readability.

Overall it looks like a mess, just to have a new design.

Doesn't look like a designer or a graphic guy had his hands on that.
I can't realized why some should replace a good and usable design which had
some practical usage and also a good readability with the "thing" we have
now.

Sorry but I will stick to the old docs as for now or use the PDF ones with
my custom style (since your colors are aweful, too).

Django should focus on a clear design which is helpful for readability and
not this stupid mess.



2014-12-16 22:48 GMT+01:00 Brad Rice :
>
> I noticed today when I went in to look something up. I like it.
>
> On Tuesday, December 16, 2014 11:12:54 AM UTC-5, Jannis Leidel wrote:
>>
>> Hi everyone,
>>
>> We're incredibly proud to share with you the new design of the Django
>> website, the documentation and the issue tracker.
>>
>> This is a long time coming and we couldn't be happier to finally ship it
>> :)
>>
>> As you can imagine, there will be bugs, so please bear with us and report
>> issues to the issue tracker at https://github.com/django/
>> djangoproject.com/issues
>>
>> More infos about the redesign and its history can be found in the blog
>> post:
>>
>>   https://www.djangoproject.com/weblog/2014/dec/15/announcing-
>> django-website-redesign/
>>
>> Happy coding, everyone!
>>
>> Jannis
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/4a4c04ca-8e57-4351-8f1b-be30e920d64a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAPDLAU6%3DHgWC_PTfRaGbQL6Tmj6tqPzcn5wdG46rkF4mBSpX0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Russell Keith-Magee]

On Wed, Dec 17, 2014 at 2:38 AM, Jannis Leidel  wrote:

>
> > On 16 Dec 2014, at 17:17, Fred Stluka  wrote:
> >
> > Jannis,
> >
> > Care to summarize what has changed?  At first glance, it looks like
> > mostly the same excellent content and the same sensible
> > organization of info, with the same useful mechanisms like the
> > ability to easily flip between different versions of the docs.
>
> Yeah, the content hasn't changed much, so you can think about this change
> as a new skin to make it look less outdated than before. We're also now
> using techniques like a responsive layout to cater to the current growing
> mobile web audience.
>

As Jannis says, it's mostly visual at the moment - with one exception: the
homepage. The old layout didn't give us space to highlight community
projects, education projects, or the Django Software Foundation. We have
those now, and we have space to put others as they arise in the community.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84_soqbWiRnouODp1zRNt4GcHfk5jCS2Jb2THKyx-0vKvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Russell Keith-Magee]

On Wed, Dec 17, 2014 at 6:55 AM, Schmitt, Christian <
c.schm...@briefdomain.de> wrote:

> Somehow I hate it. The website is the worst website I've seen since a long
> time.
> The contrast is really aweful.
> The issue Tracker got unusable due to the colors that aren't focused on
> readability.
>
> Overall it looks like a mess, just to have a new design.
>
> Doesn't look like a designer or a graphic guy had his hands on that.
> I can't realized why some should replace a good and usable design which
> had some practical usage and also a good readability with the "thing" we
> have now.
>
> Sorry but I will stick to the old docs as for now or use the PDF ones with
> my custom style (since your colors are aweful, too).
>
> Django should focus on a clear design which is helpful for readability and
> not this stupid mess.
>

Thanks for the feedback. Sorry you don't like what we've rolled out.

I can assure you that we *did* engage a "designer or graphic guy" in this
process - several in fact - and they all have significant experience in
designing "usable designs" with "practical usage". The blog post announcing
the launch has the details.

The old design was a classic, but you can't say it didn't have problems -
from a technical perspective, it was almost unusable on mobile devices;
from a functional perspective, it didn't provide a way for us as a project
to highlight community efforts, or draw attention to the DSF or provide
calls to action for people who aren't discovering Django for the first time.

If you've got specific feedback - something we can actually fix or address,
not "I don't like it" - please open a ticket. We've already had some
comments raised about contrast, which the team is looking into. If there's
something else we should know about, let us know and we can address it.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq848JSv9gw4C-RpPDuVJi994%2B%2BFOctqp8LYp%2BhqBVE%3DjSgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

[Cal Leeming]

This actually looks like an interesting framework, and I'd like to start
off with the good points.

The author (Jonas) has very kindly shared his work the community, and I
really do applaud the effort he has put into this. SPAs (single page
applications) are becoming much more common, and frameworks like this help
raise awareness about why they are so awesome. Using websockets can help in
many ways, it can greatly reduce the overhead of each request by reducing
the total req/resp size and increase async throughput by pipelining
potentially thousands of queries per second on the same connection (using
pub/sub channels). It also lets you think outside the box in terms of API
design, if you use a guaranteed pub/sub delivery mechanism then recovering
from broken connection state becomes super easy.

This project does have good intentions, but the question of "can it be used
in production" doesn't just come down to performance, and upon code
inspection I do have some concerns;

* Lack of maturity, initial commit was March 2014, not many closed/opened
issues, the author has not made it clear how long this has been in dev for.
* Reasonable amount of downloads on pypi and "stars" on github
* Code is not up to PEP8 standards
* No public CI testing
* JS does not have modular structure, does not have a sane design pattern,
and does not adhere to require/AMD
* JS has some unit tests, but they don't appear to be functional or
recently updated. On first glance, I'd say coverage is minimal and that TDD
probably hasn't been followed.
* API implementation looks a bit wonky
* Deeply integrated with Django, rather than a modular fashion which could
then be used as standalone or with other frameworks/ORMs.

For my own taste/use cases, I would say this is lacks the maturity and
stability to be considered production ready. This project feels to me like
a "prototype draft", something that could be used for a hobby project,
bleeding edge experimentation, prototype inspiration etc. If this came up
for internal code review at our work, it wouldn't pass.

But again - huge kudos to the author for what he's done so far, and I
really hope he continues to improve on it.

tl;dr - It's feels pretty alpha, YMMV :)

Cal

On Wed, Nov 12, 2014 at 4:37 AM, Suren Sth  wrote:
>
> I recently came across Swampdragon ( Visit official site
> ). I am curious can it be used in production
> sites and will it scale ? If it can be, what is the best way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/74092e59-801e-48f6-ba99-9d6231516b84%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHKQagEDXy%3D3YwEYWucUMo_aZ_yKU%3Dq%2BBaMmogmFWtv5sY-bAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Cal Leeming]

Personally I really like it.

The footer menu contrast is a little bright with the white/light green,
however it's worth noting that the color/contrast experience will vary
depending on what equipment your using. Typically if a site has been
designed on an Apple Thunderbolt/MBP Retina display, then it will look a
bit crappy on many PC monitors (even the higher quality ones). I used to
complain about site designs all the time when I was on a PC, since
switching to an MBP most of these problems disappeared. The same goes for
font weight, and indeed font rendering, typically OS X renders fonts much
cleaner than Windows. (This is on the assumption that you are using a PC).

Three spots (the design agency) look like they are using Macs in their
office according to their office photos, so this might help explain why.

However there are a few bugs;

* code.djangoproject has some indenting issues on header tags (e.g. getting
involved), and the shaded underline is weird, you can see this white
background box around it then some grey fading... very strange.
http://i.imgur.com/q2ejjq0.png

* code.djangoproject ticket list table is "bleeding" over the right hand
edge
http://i.imgur.com/ALm4eX0.png

* code.djangoproject query form is not properly designed, small font with
oddly placed form elements and incorrect use of spacing;
http://i.imgur.com/t2POMDL.png

Gotta head to bed so I'll cut this short, hope this helps though.

Cal


On Tue, Dec 16, 2014 at 11:22 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
>
> On Wed, Dec 17, 2014 at 6:55 AM, Schmitt, Christian <
> c.schm...@briefdomain.de> wrote:
>
>> Somehow I hate it. The website is the worst website I've seen since a
>> long time.
>> The contrast is really aweful.
>> The issue Tracker got unusable due to the colors that aren't focused on
>> readability.
>>
>> Overall it looks like a mess, just to have a new design.
>>
>> Doesn't look like a designer or a graphic guy had his hands on that.
>> I can't realized why some should replace a good and usable design which
>> had some practical usage and also a good readability with the "thing" we
>> have now.
>>
>> Sorry but I will stick to the old docs as for now or use the PDF ones
>> with my custom style (since your colors are aweful, too).
>>
>> Django should focus on a clear design which is helpful for readability
>> and not this stupid mess.
>>
>
> Thanks for the feedback. Sorry you don't like what we've rolled out.
>
> I can assure you that we *did* engage a "designer or graphic guy" in this
> process - several in fact - and they all have significant experience in
> designing "usable designs" with "practical usage". The blog post announcing
> the launch has the details.
>
> The old design was a classic, but you can't say it didn't have problems -
> from a technical perspective, it was almost unusable on mobile devices;
> from a functional perspective, it didn't provide a way for us as a project
> to highlight community efforts, or draw attention to the DSF or provide
> calls to action for people who aren't discovering Django for the first time.
>
> If you've got specific feedback - something we can actually fix or
> address, not "I don't like it" - please open a ticket. We've already had
> some comments raised about contrast, which the team is looking into. If
> there's something else we should know about, let us know and we can address
> it.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAJxq848JSv9gw4C-RpPDuVJi994%2B%2BFOctqp8LYp%2BhqBVE%3DjSgw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHKQagGwRn9YNFkuda7cibP2FzQBM9o7hjLF3zyM_xeZDnTc0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Sayth Renshaw]

Wow never knew mezzanine existed, that's interesting. Yes php hosting is cheap, 
but so is digitalocean and it fully supports python and django. 

Sayth

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e2a68abd-1e64-4e28-bedb-3fe8cb2bae62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Cal Leeming]

One thing to note, DigitalOcean is truly awesome but it is a no-frills
service. You get an API and raw performance at dirt cheap pricing,
everything else you have to handle yourself.

If you don't have the necessary devops/sysadmin skills, e.g. knowledge of
how to recover crashed databases, corrupt filesystems etc, then you might
want to consider something like Heroku where you can leverage the power of
build packs. This can get *very* expensive, very quickly, but for small
databases and minimal throughput, you'll be fine.

To be clear, I don't want to put you off using DigitalOcean because I
honestly think they are the best thing to happen to the unmanaged hosting
industry in a long time. At the same time, you should be aware that this
cheap, raw performance comes with a trade off. If you want to push and
forget, use Heroku. But if you want excellent performance, low pricing and
complete control, look at DigitalOcean + Packer + CircleCI. (you can push
to git, which then triggers a CircleCI build, which then triggers a packer
build, which then spins up a new VM at DO on that snapshot. However you
then need to handle destroying old instances, and automating the switch
over between instances, which would need to be some sort of LB or DNS
change over using something like CloudFlare). It gets pretty intense :)

tl-dr; Deployment of Rails vs Django has the same considerations and
complexities. You'd have to consider the above no matter which you use
anyway.

As for which would be more preferable, that comes down to personal taste.
My advice would be to review them all, pick two or three, and see which one
excites you the most.

Hope this helps dude!

Cal

On Wed, Dec 17, 2014 at 12:03 AM, Sayth Renshaw 
wrote:
>
> Wow never knew mezzanine existed, that's interesting. Yes php hosting is
> cheap, but so is digitalocean and it fully supports python and django.
>
> Sayth
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/e2a68abd-1e64-4e28-bedb-3fe8cb2bae62%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHKQagGsZLaGjJEaSC1StTVPeMdCxW7h%3D5XzNk-pLYRRf2ccFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Mark Furbee]

Looks slick to me! Clearly with mobile and responsive design in mind, but
that's what we have to keep in mind these days.

Great job to all contributors involved in this redesign!

On Tue, Dec 16, 2014 at 4:01 PM, Cal Leeming  wrote:
>
> Personally I really like it.
>
> The footer menu contrast is a little bright with the white/light green,
> however it's worth noting that the color/contrast experience will vary
> depending on what equipment your using. Typically if a site has been
> designed on an Apple Thunderbolt/MBP Retina display, then it will look a
> bit crappy on many PC monitors (even the higher quality ones). I used to
> complain about site designs all the time when I was on a PC, since
> switching to an MBP most of these problems disappeared. The same goes for
> font weight, and indeed font rendering, typically OS X renders fonts much
> cleaner than Windows. (This is on the assumption that you are using a PC).
>
> Three spots (the design agency) look like they are using Macs in their
> office according to their office photos, so this might help explain why.
>
> However there are a few bugs;
>
> * code.djangoproject has some indenting issues on header tags (e.g.
> getting involved), and the shaded underline is weird, you can see this
> white background box around it then some grey fading... very strange.
> http://i.imgur.com/q2ejjq0.png
>
> * code.djangoproject ticket list table is "bleeding" over the right hand
> edge
> http://i.imgur.com/ALm4eX0.png
>
> * code.djangoproject query form is not properly designed, small font with
> oddly placed form elements and incorrect use of spacing;
> http://i.imgur.com/t2POMDL.png
>
> Gotta head to bed so I'll cut this short, hope this helps though.
>
> Cal
>
>
> On Tue, Dec 16, 2014 at 11:22 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>>
>>
>> On Wed, Dec 17, 2014 at 6:55 AM, Schmitt, Christian <
>> c.schm...@briefdomain.de> wrote:
>>
>>> Somehow I hate it. The website is the worst website I've seen since a
>>> long time.
>>> The contrast is really aweful.
>>> The issue Tracker got unusable due to the colors that aren't focused on
>>> readability.
>>>
>>> Overall it looks like a mess, just to have a new design.
>>>
>>> Doesn't look like a designer or a graphic guy had his hands on that.
>>> I can't realized why some should replace a good and usable design which
>>> had some practical usage and also a good readability with the "thing" we
>>> have now.
>>>
>>> Sorry but I will stick to the old docs as for now or use the PDF ones
>>> with my custom style (since your colors are aweful, too).
>>>
>>> Django should focus on a clear design which is helpful for readability
>>> and not this stupid mess.
>>>
>>
>> Thanks for the feedback. Sorry you don't like what we've rolled out.
>>
>> I can assure you that we *did* engage a "designer or graphic guy" in this
>> process - several in fact - and they all have significant experience in
>> designing "usable designs" with "practical usage". The blog post announcing
>> the launch has the details.
>>
>> The old design was a classic, but you can't say it didn't have problems -
>> from a technical perspective, it was almost unusable on mobile devices;
>> from a functional perspective, it didn't provide a way for us as a project
>> to highlight community efforts, or draw attention to the DSF or provide
>> calls to action for people who aren't discovering Django for the first time.
>>
>> If you've got specific feedback - something we can actually fix or
>> address, not "I don't like it" - please open a ticket. We've already had
>> some comments raised about contrast, which the team is looking into. If
>> there's something else we should know about, let us know and we can address
>> it.
>>
>> Yours,
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CAJxq848JSv9gw4C-RpPDuVJi994%2B%2BFOctqp8LYp%2BhqBVE%3DjSgw%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://gr

Re: Devils advocate question

[Sayth Renshaw]

Definitely Thanks Cal.

Hadn't realized that with digitalocean. Been spending my time in ipython
and R and plotly and wanted to get some stuff out there.

Rails not really in the equation too much black magic.

Saw pythonanywhere, Heroku, Bitnami they just don't have a fixed cost. Eg
Bitnami says about $6.95 a month but it's about. I do something random abs
could cost myself a bucket.

Sayth

On Wed, 17 Dec 2014 11:14 AM Cal Leeming  wrote:

> One thing to note, DigitalOcean is truly awesome but it is a no-frills
> service. You get an API and raw performance at dirt cheap pricing,
> everything else you have to handle yourself.
>
> If you don't have the necessary devops/sysadmin skills, e.g. knowledge of
> how to recover crashed databases, corrupt filesystems etc, then you might
> want to consider something like Heroku where you can leverage the power of
> build packs. This can get *very* expensive, very quickly, but for small
> databases and minimal throughput, you'll be fine.
>
> To be clear, I don't want to put you off using DigitalOcean because I
> honestly think they are the best thing to happen to the unmanaged hosting
> industry in a long time. At the same time, you should be aware that this
> cheap, raw performance comes with a trade off. If you want to push and
> forget, use Heroku. But if you want excellent performance, low pricing and
> complete control, look at DigitalOcean + Packer + CircleCI. (you can push
> to git, which then triggers a CircleCI build, which then triggers a packer
> build, which then spins up a new VM at DO on that snapshot. However you
> then need to handle destroying old instances, and automating the switch
> over between instances, which would need to be some sort of LB or DNS
> change over using something like CloudFlare). It gets pretty intense :)
>
> tl-dr; Deployment of Rails vs Django has the same considerations and
> complexities. You'd have to consider the above no matter which you use
> anyway.
>
> As for which would be more preferable, that comes down to personal taste.
> My advice would be to review them all, pick two or three, and see which one
> excites you the most.
>
> Hope this helps dude!
>
> Cal
>
> On Wed, Dec 17, 2014 at 12:03 AM, Sayth Renshaw 
> wrote:
>
>> Wow never knew mezzanine existed, that's interesting. Yes php hosting is
>> cheap, but so is digitalocean and it fully supports python and django.
>>
>> Sayth
>>
>
>> --
>
>
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>
>
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/e2a68abd-1e64-4e28-bedb-3fe8cb2bae62%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/NmnbelIldz8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAHKQagGsZLaGjJEaSC1StTVPeMdCxW7h%3D5XzNk-pLYRRf2ccFw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAN2of00-OZLLg7b7NOnexUWoHyw12EvBJEYbXdZmq-ZmmjpHUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Cal Leeming]

For what it's worth, you can cap your usage on Heroku, so any exceeded
usage will just result in slow application rather than additional fees. For
a small application with minimal traffic, a database, basic monitoring etc,
you're looking around $40/month all in. Heroku is *not* a viable long term
solution for growth, as the pricing really does become ridiculously high,
but it'd perfect for small projects with low traffic projections and small
budget :)

Cal

On Wed, Dec 17, 2014 at 12:27 AM, Sayth Renshaw 
wrote:
>
> Definitely Thanks Cal.
>
> Hadn't realized that with digitalocean. Been spending my time in ipython
> and R and plotly and wanted to get some stuff out there.
>
> Rails not really in the equation too much black magic.
>
> Saw pythonanywhere, Heroku, Bitnami they just don't have a fixed cost. Eg
> Bitnami says about $6.95 a month but it's about. I do something random abs
> could cost myself a bucket.
>
> Sayth
>
> On Wed, 17 Dec 2014 11:14 AM Cal Leeming  wrote:
>
>> One thing to note, DigitalOcean is truly awesome but it is a no-frills
>> service. You get an API and raw performance at dirt cheap pricing,
>> everything else you have to handle yourself.
>>
>> If you don't have the necessary devops/sysadmin skills, e.g. knowledge of
>> how to recover crashed databases, corrupt filesystems etc, then you might
>> want to consider something like Heroku where you can leverage the power of
>> build packs. This can get *very* expensive, very quickly, but for small
>> databases and minimal throughput, you'll be fine.
>>
>> To be clear, I don't want to put you off using DigitalOcean because I
>> honestly think they are the best thing to happen to the unmanaged hosting
>> industry in a long time. At the same time, you should be aware that this
>> cheap, raw performance comes with a trade off. If you want to push and
>> forget, use Heroku. But if you want excellent performance, low pricing and
>> complete control, look at DigitalOcean + Packer + CircleCI. (you can push
>> to git, which then triggers a CircleCI build, which then triggers a packer
>> build, which then spins up a new VM at DO on that snapshot. However you
>> then need to handle destroying old instances, and automating the switch
>> over between instances, which would need to be some sort of LB or DNS
>> change over using something like CloudFlare). It gets pretty intense :)
>>
>> tl-dr; Deployment of Rails vs Django has the same considerations and
>> complexities. You'd have to consider the above no matter which you use
>> anyway.
>>
>> As for which would be more preferable, that comes down to personal taste.
>> My advice would be to review them all, pick two or three, and see which one
>> excites you the most.
>>
>> Hope this helps dude!
>>
>> Cal
>>
>> On Wed, Dec 17, 2014 at 12:03 AM, Sayth Renshaw 
>> wrote:
>>
>>> Wow never knew mezzanine existed, that's interesting. Yes php hosting is
>>> cheap, but so is digitalocean and it fully supports python and django.
>>>
>>> Sayth
>>>
>>
>>> --
>>
>>
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-users+unsubscr...@googlegroups.com.
>>
>>
>>> To post to this group, send email to django-users@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/e2a68abd-1e64-4e28-bedb-3fe8cb2bae62%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-users/NmnbelIldz8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CAHKQagGsZLaGjJEaSC1StTVPeMdCxW7h%3D5XzNk-pLYRRf2ccFw%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAN2of00-OZLLg7

Re: Devils advocate question

[Tim Chase]

On 2014-12-17 00:14, Cal Leeming wrote:
> One thing to note, DigitalOcean is truly awesome but it is a
> no-frills service. You get an API and raw performance at dirt cheap
> pricing, everything else you have to handle yourself.

I'd call it "cheap pricing", not "dirt cheap pricing" since PHP
hosting can be had for $3/mo or even pushing free, depending on the
conditions & limitations you're willing to accept.  For a small
one-off site, demo, or playground, the difference between hosting for
$60/yr vs. under $36 may make or break the hosting decision.

Ubiquitous availability and ease of deployment are the only things
that PHP has going for it, IMHO.  If Django/Python could make
deployment as easy & ubiquitous as PHP, the world would be a much
better place. :-D

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20141216205331.143cf0f6%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Content using {% include %} not appearing on detailed page Django

[Fred Stluka]

Andrew,

I'm not sure, but since no one else has answered yet...

Maybe you can't pass an object as a keyword argument to include,
can only pass strings?  I've done it often with strings, but never
with an object.  Try:

{% include "sidebar.html" title=object.title %}

and in the included file, use simply:

{{title}}

It seems odd that there'd be a restriction like this since I'm sure
you can pass objects to templates from views, but it's worth
trying.  May be a good workaround, or may get you a different
error message that tips you off to what the real problem is.

--Fred

Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

On 12/16/14 2:27 PM, Andrew Nguyen wrote:


I'm having some problems getting some of my content to appear on my 
detailed page view, which I have in two separate html files that are 
being pulled in using |{% include %}|. Inside my two files, 
|slider.html|and |sidebar.html|, I'm using tags like 
|{{article.title}}| to grab specific information I need about an article.


*TRIED: *
- Changing syntax in the two included files to |{{object.title}}| did 
not work.


- I've tried doing|{% include "sidebar.html" article=object %}|in 
my|detailed.html|and it did not work. Instead, I would get an 
error|TemplateSyntaxError at /gone-home Unknown argument for 
u'include' tag: u'article=object'.|


- Also tried doing `{% include "sidebar.html" with article=object %} 
did not work either.


*detailed.html*

|
{%  include"sidebar.html"  %}


 {{object.title}}
 {{object.pubDate|date:"l, F j, Y"  }}  |  
{{object.author}}
 
 
 

 {{object.body|linebreaks}}
 

 
 {%  include"slider.html"  %}

|

*slider.html*

|
 
 
 
 {{article.title}}
 
 
 |

*sidebar.html*

|
 {%  for  articlein  object_list|slice:":5"  %}
 
 
 
 
 {{article.title|truncatewords:"4"}}
 
 {%  endfor%}
 |

*models.py*

|from  django.dbimport  models
from  django.core.urlresolversimport  reverse

# Create your models here.
class  FullArticleQuerySet(models.QuerySet):
 def  published(self):
 return  self.filter(publish=True)

class  FullArticle(models.Model):
 title=  models.CharField(max_length=150)
 author=  models.CharField(max_length=150)
 slug=  models.SlugField(max_length=200,  unique=True)
 pubDate=  models.DateTimeField(auto_now_add=True)
 updated=  models.DateTimeField(auto_now=True)
 category=  models.CharField(max_length=150)
 # gameRank = models.PositiveSmallIntegerField(default=0)
 heroImage=  models.CharField(max_length=250,  blank=True)
 relatedImage=   models.CharField(max_length=250,  blank=True)
 body=   models.TextField()
 publish=  models.BooleanField(default=True)

 objects=  FullArticleQuerySet.as_manager()

 def  __str__(self):
 return  self.title

 def  get_absolute_url(self):
 return  reverse("FullArticle_detailed",  kwargs={"slug":  self.slug})

 def  random(self):
 return  
self.get_queryset().order_by('?').values('title','author','heroImage','body').first()

 class  Meta:
 verbose_name=  "Blog entry"
 verbose_name_plural=  "Blog Entries"
 ordering=  ["-pubDate"]|

*views.py*

|from  django.viewsimport  generic
from  .  import  models

# Create your views here.
class  BlogIndex(generic.ListView):
 queryset=  models.FullArticle.objects.published()
 template_name=  "list.html"
 # paginate_by = 2

class  BlogDetail(generic.DetailView):
 model=  models.FullArticle
 template_name=  "detailed.html"|
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/343cde15-36ab-4432-836b-5947922e48b2%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this 

Re: ANN: Django website redesign launched

[Torsten Bronger]

Hallöchen!

Cal Leeming writes:

> [...]
>
> The footer menu contrast is a little bright with the white/light
> green, however it's worth noting that the color/contrast
> experience will vary depending on what equipment your
> using. Typically if a site has been designed on an Apple
> Thunderbolt/MBP Retina display, then it will look a bit crappy on
> many PC monitors (even the higher quality ones).  [...]

I think this doesn't matter.  Besides the fact that my screen is
calibrated and I nevertheless tilt the screen when I visit the new
website to gain contrast, a website should be optimized for
sub-optimal conditions rather than the best ones.

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/87zjamzz30.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7: How to migrate data between two external apps

[John-Scott]

My 'solution' was very smelly:

   - created the migration in 'my_app' as mentioned in my previous post
   - pushed this change to production to run
   - removed 'foo_tag' from INSTALLED_APPS *AND* deleted the migration file 
   (which meant also manually deleting the history of this migration from the 
   django_migrations table).

It was hard to hold my nose through this experience but it worked. Would be 
great to have a general solution that could be shared with others but in 
the meantime, I'll settle for being able to get on with the rest of my life.

On Tuesday, December 16, 2014 9:05:35 AM UTC-5, Markus Holtermann wrote:
>
> Hey John-Scott,
>
> I'm afraid but I don't see an obvious solution. There are 2 ways you could 
> work on the issue, I don't like either:
>
> 1. remove all references to the "foo_tag" app from all migration files
>
> 2. make use of the MIGRATION_MODULES settings:
>
> 2.1. create a package "path.to.foo_tag_legacy"
> 2.2. inside create an empty migration "0001_initial"
> 2.3. define MIGRATION_MODULES={"foo_tag": "path.to.foo_tag_legacy"}
>
> As said, both seem ugly to me. I don't know which way I'd proceed.
>
> You might get it working by squashing migrations, but certainly not 
> without manually writing those migration files.
>
> /Markus
>
> On Saturday, December 13, 2014 6:26:17 PM UTC+1, John-Scott wrote:
>>
>> Say I decided to switch from a third party app foo-tags to app bar-tags. 
>> Their Tag models are mostly identical so I just need to move the data from 
>> foo-tag to bar-tag. Since I don't control their migrations, I'd need to 
>> create a migration in one of my own apps:
>>
>> ./manage.py makemigrations my_app --empty
>>
>> In this migration I'd need to explicitly list the dependencies on these 
>> external apps (otherwise was getting errors that the foo and bar apps were 
>> not available in the app registry):
>>
>> # -*- coding: utf-8 -*-
>> from __future__ import unicode_literals
>>
>> from django.db import models, migrations
>>
>> def migrate_tags(apps, schema_editor):
>> FooTag = apps.get_model('foo_tag', 'FooTag')
>> BarTag = apps.get_model('bar_tag', 'BarTag')
>> for old_tag in FooTag.objects.all():
>> new_tag = BarTag.objects.create(name=old_tag.name)
>>
>> class Migration(migrations.Migration):
>> dependencies = [
>> ('my_app', '0001_initial'),
>> ('foo_tag', '0001_initial'),
>> ('bar_tag', '0001_initial'),
>> ]
>>
>> operations = [
>> migrations.RunPython(migrate_tags)
>> ]
>>
>>
>> The migration itself works as expected. However if I now remove foo_tag 
>> from INSTALLED_APPS, Django will now give an error:
>>
>> KeyError: "Migration my_app.0002_auto_20141212_1951 dependencies 
>> reference nonexistent parent node ('foo_tag', '0001_initial')"
>>
>> What's the correct way to handle migrating data between 3rd party apps 
>> where one of the apps is eventually removed?
>>
>> Thanks,
>> John-Scott
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/97020def-7278-4416-92a2-9088455b4ff6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Daniele Procida]

On Tue, Dec 16, 2014, Sayth Renshaw  wrote:

>Why hasn't a cms been designed off django or python? A language cultural
>effect yoy would think python would be more stable than php/drupal.

You mean like django CMS, to Fein CMS, Mezzanine, Wagtail or any of the other 
Django CMSes?

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20141217075832.1415961390%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.