Re: ANN: Django website redesign launched

[Sithembewena Lloyd Dube]

I like the new design. A lot. Thank you!

On Wed, Dec 17, 2014 at 6:20 AM, Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
>
> 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.
>


-- 
Regards,
Sithu Lloyd Dube

-- 
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/CAH-SnCCJDXO9K9uqxjBeXHV0WmeZ8QdwGhVYqdJEH86RxKs8qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Cal Leeming]

I am inclined to agree that a site should try and look the same on all
devices (in terms of color/contrast etc) but this simply isn't possible in
the real world. The majority of users do not calibrate their equipment, and
even when they do, the result will vary massively depending on the quality
of your gear. Don't get me wrong, there is some equipment out there that
will render as beautifully as the Apple gear, but it will be a very small
percentage of users that owns this. I've seen laptops retailing over £1k
which are damn near impossible to calibrate.

Furthermore, it's quite difficult to make a beautiful "retina" design
whilst also satisfying the needs of other devices. I had this discussion
with another company back when I was a PC user, and their response was
simply "our target audience for our site is Mac users, tough luck." In my
own experience, to compensate for these subpar devices you have to avoid
things like "thin" font weights, close contrasts and even certain colors.

One option is to use two different styles and switch them out using feature
detection. Or you could try and construct a design/color scheme which
satisfies both needs (though I'm yet to see one). Or you can choose based
on your target audience.

Note: design is not my first skill and these are only things I've picked up
from experience, working with other designers and reading articles. I
couldn't explain the in-depths of why these problems happen.

Cal

On Wed, Dec 17, 2014 at 4:20 AM, Torsten Bronger <
bron...@physik.rwth-aachen.de> wrote:
>
> 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.
>

-- 
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/CAHKQagF%3Dts3Nh_3tSpkaHtbdiXru5tR3zPxXYTG0GAYzUnqjaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Cal Leeming]

On Wed, Dec 17, 2014 at 2:53 AM, Tim Chase 
wrote:
>
> 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
>

Deployment is completely separate to the code base, and the challenges
faced from deploying a PHP/Rails app is exactly the same as you'd face with
Python. It all comes down to what your release process is.. it could be
argued that PHP can just be uploaded via FTP to XYZ host, but it could (and
should) also be argued that this is not how you should do deployment
properly.

The decision of language, framework, hosting, devops workflow (e.g.
deployment etc) does not have a one size fits all. These decisions should
be made based on your own use case and situation, including the skill set
of your team, timescales, project goals, expected lifetime of the
application etc.

Sadly, despite all the tooling that exists, none of them really satisfy
real world needs. And the ones that do are either hideously complex or
excessively priced. There will always be some trade offs.


> -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.
>

-- 
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/CAHKQagGP04LENvdX0CE0a-Z91QSP%2BhXYuBOzC%3DGj3_NBbdk37A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Roseman]

On Tuesday, 16 December 2014 19:27:41 UTC, 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.htmland 
> sidebar.html, I'm using tags like {{article.title}} to grab specific 
> information I need about an article. 
>

But your code shows that you are doing something completely different: 
you're not grabbing specific information about the article in question, 
you're trying to get details for *all* articles and iterate through them. 
Your detail view presumably doesn't passs any reference called 
`object_list`, so your loop doesn't work. Passing in parameters to include 
won't help, because you don't have the information in the first place.

What you really need here is a custom inclusion tag 
(https://docs.djangoproject.com/en/1.7/howto/custom-template-tags/#inclusion-tags)
 
which queries the object_list and passes it to the sidebar template for 
rendering.

--
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+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/63cdb829-9b12-4924-9d7e-cda6dadeb866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Andrea]

The new web design look really modern, clean and nice.
Something I would suggest is to reduce the "Smartphone feeling" on desktop
computers.
For example, I have a 26" monitor, and in the "Overview" page I can not
look at the 5 overview points at the same time. I need to keep scrolling up
and down.
As the content is not necessarily supposed to be viewed sequentially, I
personally prefer to have more content at the same time in the view.

Andrea

2014-12-17 9:59 GMT+01:00 Cal Leeming :
>
> I am inclined to agree that a site should try and look the same on all
> devices (in terms of color/contrast etc) but this simply isn't possible in
> the real world. The majority of users do not calibrate their equipment, and
> even when they do, the result will vary massively depending on the quality
> of your gear. Don't get me wrong, there is some equipment out there that
> will render as beautifully as the Apple gear, but it will be a very small
> percentage of users that owns this. I've seen laptops retailing over £1k
> which are damn near impossible to calibrate.
>
> Furthermore, it's quite difficult to make a beautiful "retina" design
> whilst also satisfying the needs of other devices. I had this discussion
> with another company back when I was a PC user, and their response was
> simply "our target audience for our site is Mac users, tough luck." In my
> own experience, to compensate for these subpar devices you have to avoid
> things like "thin" font weights, close contrasts and even certain colors.
>
> One option is to use two different styles and switch them out using
> feature detection. Or you could try and construct a design/color scheme
> which satisfies both needs (though I'm yet to see one). Or you can choose
> based on your target audience.
>
> Note: design is not my first skill and these are only things I've picked
> up from experience, working with other designers and reading articles. I
> couldn't explain the in-depths of why these problems happen.
>
> Cal
>
> On Wed, Dec 17, 2014 at 4:20 AM, Torsten Bronger <
> bron...@physik.rwth-aachen.de> wrote:
>
>> 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.
>>
>  --
> 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/CAHKQagF%3Dts3Nh_3tSpkaHtbdiXru5tR3zPxXYTG0GAYzUnqjaA%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/CAAPQ7Y3WxXHJe2aivmZMFX3V80CgwojCBpY0hwha8tVfQUj6sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

DjangoCon Europe 2015

[Daniele Procida]

Hello everyone, here's DjangoCon Europe 2015: 

.

Hope to see you in Cardiff in June!

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/20141217095509.715706034%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Torsten Bronger]

Hallöchen!

Cal Leeming writes:

> I am inclined to agree that a site should try and look the same on
> all devices (in terms of color/contrast etc)

I didn't mean this.  What I meant was that a webpage should work
well on all devices in terms of legibility and usability.  It may
work better on one device than on the other, but there should be a
minimal quality.

As far as I am concerned, just add contrast and I'm fine with the
new design.  And I'm sure that the higher-contrast scheme would also
work on Apple devices.

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/87mw6mlgyr.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Jorge C . Leitão]

Dear Django community,

I would like to congratulate you very much for this. I'm very pleased to 
see that the work in Django is much better presented to the world, which I 
think we all agree is an important component of the project.

Generally speaking, I like very much the overall look and feel of the 
website. I imagine it is very hard to agree on them, specially since it is 
a component that has some intrinsic subjectivity.

I have a question regarding the layout:

In the previous website there was a noticeable difference between the 
website UI and the UI of the issue tracker. Are we aiming to keep that 
difference or do we aim to make them indistinguishable?

This is because it seems that some elements of the tracker were changed to 
blend with the new look, but others don't. Specifically:

- In the main content of the issue tracker the horizontal lines have a 
shadow in the bottom; The other sections don't.
- In the issue tracker, some content is boxed (e.g. wiki), while other 
doesn't (new ticket), and the boxes are corner-rounded (while the website 
has rounded elements besides buttons).
- In the wiki of the issue tracker, the font seems to be "blurred"(?), 
compare with sidebar.

I would prefer the same look of the issue tracker for consistency, but 
since that section of the website is aimed to developers of Django, there 
can be a rational to make it different. Could we clarify this so we know 
what is a bug to report and what is an intended feature?

In any case, the quality of Django website conveys now much better the 
quality of the Django project. Thank you for that.

Cheers,
Jorge


On Tuesday, December 16, 2014 5:09:55 PM UTC+1, 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/c3d543e5-ac54-4df1-bd38-1d020d760fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Using django-nocaptcha-recaptcha problem

[Hossein Rashnoo]

Hi, I use *django-nocaptcha-recaptcha* in my site and it worked perfect. 
But after that i tried several times for fill a form , google not recognize 
me as human with a click and tried to show me a challenge image. *The 
problem is **challenge image not appear.*I attached the photo of this 
problem.
Sorry for bad English.



-- 
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/d40c3896-12a9-4e39-93a6-6dda8d6cc121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Mike Dewhirst]

On 17/12/2014 7:59 PM, Cal Leeming wrote:

you have to avoid
things like "thin" font weights


I'm interested to know what fonts are being used so I can install them 
on my machine. Chrome and Firefox make text on the new site look ragged. 
Windows 8.1.


Other than that,  +1 

Mike

--
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/549168B1.1060804%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Rakan Alhneiti]

God job everyone!

Do you think the Overview page  should 
have the logos of the "Sites using Django"? it would be more visually 
appealing, in addition, people might be more aware of the logos than just 
plain names. What do you think?

Best Regards,
Rakan

On Tuesday, December 16, 2014 5:12:54 PM UTC+1, 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/845e4c2a-ff65-4691-b82d-02b5dfb193e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Sithembewena Lloyd Dube]

I second Rakan's suggestion regarding the use of logos. Here's a perfect
example of the concept (and how effective it is):
http://www.pylonsproject.org/

On Wed, Dec 17, 2014 at 2:04 PM, Rakan Alhneiti 
wrote:
>
> God job everyone!
>
> Do you think the Overview page  
> should
> have the logos of the "Sites using Django"? it would be more visually
> appealing, in addition, people might be more aware of the logos than just
> plain names. What do you think?
>
> Best Regards,
> Rakan
>
>
> On Tuesday, December 16, 2014 5:12:54 PM UTC+1, 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/845e4c2a-ff65-4691-b82d-02b5dfb193e6%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Regards,
Sithu Lloyd Dube

-- 
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/CAH-SnCAPso1az%2B0egFvfVNmWssBwe-D2AcwDu03rtn6tVAi%2Bow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Rob]

On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt 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.
>

Clearly.  My audit extension flags 47 contrast problems on the home page 
alone.  The site is not very accessible contrast wise.

Doesn't look like a designer or a graphic guy had his hands on that.
>

It clearly had a designer,  but they don't grok usability.

I hate to be "that guy" but this is not really an improvement other than it 
works on mobile now ...

-- 
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/4491aa9f-9b06-4295-9411-57b9879271b5%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 ?

[jonas hagstedt]

You are right about pep8, there were two pep8 violations in there (fixed 
that after reading this).

*  There is a CI setup with Codeship. After reading this I made the badge 
available on Github (good point).
*  It is deeply integrated with Django by design.
*  I am reviewing the JavaScript, but it works so there is nothing stopping 
anyone from using it (but you are right about the JS).
*  I honestly don't remember the exact date I started developing 
SwampDragon but I don't think it was long before the initial commit.

I am interested in knowing what it is about the API implementation that 
looks wonky. 
It's always good with fresh eyes on a project, so I would love to hear more 
details on this.

It's been good to read these comments as you tend to get tunnel vision when 
you work on something after a while.

None of these points are actually qualifying if you should use it in 
production or not (don't get me wrong, the points are all good).

Should you use this in production?:
*  Does it perform well enough?
*  Is it secure enough?

and these two questions depends a lot on your code base / project 
requirements.

I would love to hear more about the wonky API though if you wouldn't mind.

Cheers


On Wednesday, December 17, 2014 12:23:52 AM UTC+1, Cal Leeming wrote:
>
> 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...@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/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 

Re: ANN: Django website redesign launched

[Daniele Procida]

On Wed, Dec 17, 2014, Rob  wrote:

>On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt 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.
>>
>
>Clearly.  My audit extension flags 47 contrast problems on the home page 
>alone.  The site is not very accessible contrast wise.
>
>Doesn't look like a designer or a graphic guy had his hands on that.
>>
>
>It clearly had a designer,  but they don't grok usability.
>
>I hate to be "that guy" but this is not really an improvement other than it 
>works on mobile now ...

We'd hate you to be "that guy" too. However, so far you are "that guy", since 
merely announcing that you have identified numerous accessibility issues is 
useless. 

The repository is . It's all open. 
If you're able to suggest or make improvements, you know what to do if you want 
to stop being "that guy".

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/20141217133711.440709691%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Vijay Khemlani]

I really like the new design, the old one felt way too cluttered with too
much information on the main page and overwhelmed new users.

And... haters gonna hate.

Congrats to the team!

On Wed, Dec 17, 2014 at 10:37 AM, Daniele Procida  wrote:
>
> On Wed, Dec 17, 2014, Rob  wrote:
>
> >On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt 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.
> >>
> >
> >Clearly.  My audit extension flags 47 contrast problems on the home page
> >alone.  The site is not very accessible contrast wise.
> >
> >Doesn't look like a designer or a graphic guy had his hands on that.
> >>
> >
> >It clearly had a designer,  but they don't grok usability.
> >
> >I hate to be "that guy" but this is not really an improvement other than
> it
> >works on mobile now ...
>
> We'd hate you to be "that guy" too. However, so far you are "that guy",
> since merely announcing that you have identified numerous accessibility
> issues is useless.
>
> The repository is . It's all
> open. If you're able to suggest or make improvements, you know what to do
> if you want to stop being "that guy".
>
> 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/20141217133711.440709691%40mail.wservices.ch
> .
> 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/CALn3ei2g2S3t6Y36xjyfObwHUjAZFFbiSHAtzc2DtRxWf9TcxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Customize admin site labels

[Collin Anderson]

Hi,

I think this is what you want:
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#customizing-adminsite

Collin

On Monday, December 15, 2014 12:00:17 PM UTC-5, Xairi Valdivia Maker wrote:
>
> Hi all.
>
> I was trying to customize the Django admin site today. I'm strating trying 
> to change the labels Django admin in the login and in the admin site for 
> something else, but i can't.
>
> I found this: 
>
> https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#adminsite-attributes
>
> But i don't know where i have to set those attributes.
>
> Thanks in advance
>

-- 
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/af6837d0-c5bf-4f5e-8ded-cbe854474188%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django template auto format tool?

[Collin Anderson]

Hi Abraham,

If you made a took, I'd use it. :)

Collin

On Saturday, December 13, 2014 9:53:56 PM UTC-5, Abraham Varricatt wrote:
>
> Hello,
>
> Is there any command-line based tool which would let one auto-format 
> Django template files? Ideally, the tool should also be used to format 
> HTML, CSS and .JS files too. 
>
> I've recently inherited a bad-looking code base and want to clean it up. 
> Have heard of the PEP8 autoformatter, but that just works for Python files, 
> right?
>
> -Abraham V.
>
>

-- 
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/c1676086-71c3-4292-a94a-09aded58685b%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 ?

[Cal Leeming]

Thanks for the reply, I was almost sure there were more PEP8 violations,
line length and such, but perhaps my eyes failed me so I'll recheck that.

And sure I'd be more than happy to go into detail/specifics on my reasoning
about the API, I've got two other promised reviews in the queue (Django
itself and DRF) so it'll be a couple of weeks before I can spend some time
on this.

I completely agree on the tunnel vision, I've worked on projects in the
past where I was so sure it was the right way, and then others came along
and absolutely destroyed my code with their review (and they were right to
do so). Code reviews can be a bit demoralizing sometimes, especially when
you have vested a lot of time/effort into them, hence why I tried to focus
on the positives more than the negatives.

Cal

On Wed, Dec 17, 2014 at 1:33 PM, jonas hagstedt  wrote:
>
> You are right about pep8, there were two pep8 violations in there (fixed
> that after reading this).
>
> *  There is a CI setup with Codeship. After reading this I made the badge
> available on Github (good point).
> *  It is deeply integrated with Django by design.
> *  I am reviewing the JavaScript, but it works so there is nothing
> stopping anyone from using it (but you are right about the JS).
> *  I honestly don't remember the exact date I started developing
> SwampDragon but I don't think it was long before the initial commit.
>
> I am interested in knowing what it is about the API implementation that
> looks wonky.
> It's always good with fresh eyes on a project, so I would love to hear
> more details on this.
>
> It's been good to read these comments as you tend to get tunnel vision
> when you work on something after a while.
>
> None of these points are actually qualifying if you should use it in
> production or not (don't get me wrong, the points are all good).
>
> Should you use this in production?:
> *  Does it perform well enough?
> *  Is it secure enough?
>
> and these two questions depends a lot on your code base / project
> requirements.
>
> I would love to hear more about the wonky API though if you wouldn't mind.
>
> Cheers
>
>
> On Wednesday, December 17, 2014 12:23:52 AM UTC+1, Cal Leeming wrote:
>>
>> 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, s

Re: AttributeError raised when calling form's superclass clean() method, however the form doesn't get filled with errors

[Collin Anderson]

Hi Hector,

I think your clean() method needs to return cleaned_data.

Collin

On Monday, December 15, 2014 2:39:35 PM UTC-5, Héctor Urbina wrote:
>
> This is my view:
>
> def perfilInversionCliente(request, cliente_pk):
>   objetos = {}
>   cliente = get_object_or_404(Cliente, pk=cliente_pk)
>   targetAllocationsForm = TargetAllocationsForm(cliente=cliente)
>
>   if request.method == "POST":
> targetAllocationsForm = TargetAllocationsForm(request.POST)
> if targetAllocationsForm.is_valid():
>   data = targetAllocationsForm.cleaned_data
>   for k in data:
> editar = False
> if isinstance(k, CategoriaActivo):
>   try:
> currentAlloc = cliente.targetCategoriaAllocations.filter(
> categoria=k).latest("fecha")
> if currentAlloc.allocation != data[k]:
>   editar = True
>   except DoesNotExist:
> editar = True
>   if editar:
> newAlloc = TargetCategoriaAllocation(cliente=cliente, 
> categoria=k, allocation=data[k], fecha=datetime.datetime.now(), editor=
> request.user)
> newAlloc.save()
> if isinstance(k, SubcategoriaActivo):
>   try:
> currentAlloc = cliente.targetSubcategoriaAllocations.filter(
> subcategoria=k).latest("fecha")
> if currentAlloc.allocation != data[k]:
>   editar = True
>   except DoesNotExist:
> editar = True
>   if editar:
> newAlloc = TargetSubcategoriaAllocation(cliente=cliente, 
> subcategoria=k, allocation=data[k], fecha=datetime.datetime.now(), editor=
> request.user)
> newAlloc.save()
> else:
>   pdb.set_trace()
>
>   objetos["targetAllocationsForm"] = targetAllocationsForm
>   categorias = {}
>   for cat in CategoriaActivo.objects.all():
> categorias[cat] = cat.subcategorias.all()
>   objetos["categorias"] = categorias
>   objetos["cliente"] = cliente
>   template = loader.get_template('carteras/perfilInversionista.html')
>   context = RequestContext(request, objetos)
>   return HttpResponse(template.render(context))
>
>
> The keys of the form's fields are not strings, they are python objects... 
> At first I though that wouldn't work, but I tested the form in a shell and 
> it seems to work just fine.
>
> On Monday, December 15, 2014 4:23:36 PM UTC-3, Daniel Roseman wrote:
>>
>> You should show your view. 
>>
>> You should not call clean directly: it is called automatically by 
>> is_valid. 
>>
>> Also note that the keys of self.fields are strings, so neither your if 
>> nor your elif will ever execute. 
>> -- 
>> 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+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/7acb5d42-bd6b-4cef-b044-040c93b1418f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Marcelo Barbero]

I don't like the new design.

Subjective flaws: too much space wasted, childish style (I exclusively
use PCs to access the web).

Objective flaws: fonts look ugly, with unclear edges and weird shapes
in the "w" letter ( in my Windows XP with Firefox and Chrome).

Marcelo


2014-12-17 10:28 GMT-03:00 Rob :
> On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt 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.
>
>
> Clearly.  My audit extension flags 47 contrast problems on the home page
> alone.  The site is not very accessible contrast wise.
>
>> Doesn't look like a designer or a graphic guy had his hands on that.
>
>
> It clearly had a designer,  but they don't grok usability.
>
> I hate to be "that guy" but this is not really an improvement other than it
> works on mobile now ...
>
> --
> 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/4491aa9f-9b06-4295-9411-57b9879271b5%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/CAOhPkZzEHfTWULA6L%3DirCqhR-3prmNr4Zdj1A21gdXTga-%2BegA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Tim Chase]

On 2014-12-16 19:34, Jannis Leidel wrote:
>> On 16 Dec 2014, at 18:37, Tim Chase wrote:
>> 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.
>>
>> 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.

Done.

https://github.com/django/djangoproject.com/issues/217

Thanks for all the effort put into improving the site and its
accessibility.

-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/20141217075847.2367db20%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Rob]

On Wednesday, December 17, 2014 8:39:21 AM UTC-5, Daniele Procida wrote:
>
>
> We'd hate you to be "that guy" too. However, so far you are "that guy", 
> since merely announcing that you have identified numerous accessibility 
> issues is useless. 
>

Ok.  Tell the designer to google "chrome accessibility tester 
extension" and install the first match.

It will then flag the places where the Web Content Accessibility Guidelines 
are not being followed; http://www.w3.org/TR/WCAG/#visual-audio-contrast

The repository is  >.
>  
> It's all open. If you're able to suggest or make improvements, you know 
> what to do if you want to stop being "that guy". 
>

I'm not a designer.  I can't make good suggestions on how to improve 
things, since I would most definitely make it worse.
 

-- 
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/279b3513-5c92-4ec6-a878-932e6be58f79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django template auto format tool?

[Abraham Varricatt]

Ha, ha. :D

I'm no expert. I need the tool myself to learn a lot of this stuff.

-Abraham V.


On Wed, Dec 17, 2014 at 7:15 PM, Collin Anderson 
wrote:
>
> Hi Abraham,
>
> If you made a took, I'd use it. :)
>
> Collin
>
> On Saturday, December 13, 2014 9:53:56 PM UTC-5, Abraham Varricatt wrote:
>>
>> Hello,
>>
>> Is there any command-line based tool which would let one auto-format
>> Django template files? Ideally, the tool should also be used to format
>> HTML, CSS and .JS files too.
>>
>> I've recently inherited a bad-looking code base and want to clean it up.
>> Have heard of the PEP8 autoformatter, but that just works for Python files,
>> right?
>>
>> -Abraham V.
>>
>>  --
> 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/FOnYD1XMWRo/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/c1676086-71c3-4292-a94a-09aded58685b%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/CADeSw2yA3bO5cSEskDRYTOpNKWOb_km-mKYskwdBtS11Mz%3DP7Q%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 ?

[jonas hagstedt]

I ignore E501 as I find it a silly rule, but if I don't then there will be 
pep8 issues a plenty, so that would explain it.

Thanks for taking the time to looking at the code though. 
Next version will have some JS rewrite (hopefully without breaking 
backwards compatibility)


On Wednesday, December 17, 2014 2:46:12 PM UTC+1, Cal Leeming wrote:
>
> Thanks for the reply, I was almost sure there were more PEP8 violations, 
> line length and such, but perhaps my eyes failed me so I'll recheck that. 
>
> And sure I'd be more than happy to go into detail/specifics on my 
> reasoning about the API, I've got two other promised reviews in the queue 
> (Django itself and DRF) so it'll be a couple of weeks before I can spend 
> some time on this.
>
> I completely agree on the tunnel vision, I've worked on projects in the 
> past where I was so sure it was the right way, and then others came along 
> and absolutely destroyed my code with their review (and they were right to 
> do so). Code reviews can be a bit demoralizing sometimes, especially when 
> you have vested a lot of time/effort into them, hence why I tried to focus 
> on the positives more than the negatives.
>
> Cal
>
> On Wed, Dec 17, 2014 at 1:33 PM, jonas hagstedt  > wrote:
>>
>> You are right about pep8, there were two pep8 violations in there (fixed 
>> that after reading this).
>>
>> *  There is a CI setup with Codeship. After reading this I made the badge 
>> available on Github (good point).
>> *  It is deeply integrated with Django by design.
>> *  I am reviewing the JavaScript, but it works so there is nothing 
>> stopping anyone from using it (but you are right about the JS).
>> *  I honestly don't remember the exact date I started developing 
>> SwampDragon but I don't think it was long before the initial commit.
>>
>> I am interested in knowing what it is about the API implementation that 
>> looks wonky. 
>> It's always good with fresh eyes on a project, so I would love to hear 
>> more details on this.
>>
>> It's been good to read these comments as you tend to get tunnel vision 
>> when you work on something after a while.
>>
>> None of these points are actually qualifying if you should use it in 
>> production or not (don't get me wrong, the points are all good).
>>
>> Should you use this in production?:
>> *  Does it perform well enough?
>> *  Is it secure enough?
>>
>> and these two questions depends a lot on your code base / project 
>> requirements.
>>
>> I would love to hear more about the wonky API though if you wouldn't mind.
>>
>> Cheers
>>
>>
>> On Wednesday, December 17, 2014 12:23:52 AM UTC+1, Cal Leeming wrote:
>>>
>>> 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 i

Django ManyToManyField Not Displaying in Template

[Rodney Lewis]

Hey All:

I need my template to iterate through each PartModel and then iterate 
through the PartModels associated (through a self-referential 
ManyToManyField) with the PartModel in question. I am doing everything I'm 
supposed to be doing according to my reading of the "entry_set syntax" 
section of the "Making Queries" section of the docs to no avail.
http://stackoverflow.com/questions/27527717/django-manytomanyfield-not-displaying-in-template

Thank you in advance for any assistance!

-- 
Rodney Lewis
http://www.youtube.com/pyrodney

-- 
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/e5684a8d-21e2-4d21-ae94-c235804b35d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to set up a junction table in Django

[Ben Gorman]

(I'm copying my question from Stack Overflow here 

 because 
it didn't get any answers.  Please let me know if it's confusing.)

I'm trying to figure out the best way to model this data structure. I want 
to have a table of "Players" and and table of "Games" such that each game 
includes two or more players. E.g.

Players

PlayerID | PlayerName1| John2| Sue3| Bob

Games

GameID | GameDate1  | 1/1/20142  | 2/1/2014

GamePlayers (junction table)

GamePlayerID | GameID | PlayerID 1| 1  | 12| 1  
| 23| 1  | 34| 2  | 25| 2  | 
NULL

Notice the NULL value. This basically says "Game 2" consists of player 2 *and 
one undetermined* player. This functionality is what I need to replicate in 
Django. This is what I tried.

Models.py

class Player(models.Model):
player_name = models.CharField(max_length=60)
class Game(models.Model):
players = models.ManyToManyField(Player, blank=True)
game_date = models.DateField(null=True, blank=True)

But with this setup I can't seem to replicate the functionality I described 
above. How do I accomplish this?

-- 
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/15216524-522f-41ec-a78b-bddcdcf6ad9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

eCommerce Search

[John Rodkey]

Hi All, I apologize if this has been answered, but what is the best way to 
search/query a model based on filters. 

For example, say we are setting up a shoe site. What is the best way to 
allow customers to search for shoes by brand, color, size, and/or price.  I 
would prefer to make these dropdowns in the templates, I'm just not sure 
how to build this functionality in the view.

I would appreciate any direction.

-- 
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/a4b1bfcb-5897-479f-b940-9e82df409947%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]

I agree, a general "here's how you should do it" section in the docs should 
be added. Would you mind opening a ticket on 
https://code.djangoproject.com/ where you state the problem (e.g. link to 
this discussion). Thanks.

/Markus

On Wednesday, December 17, 2014 6:01:05 AM UTC+1, John-Scott wrote:
>
> 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/a2a0cce2-6226-4b24-8c7d-bce7fbf74aae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

UUID as primary key for Oracle backend

[Joris Benschop]

Hi list

I'm trying to use Django 1.7.2 with an Oracle 11.2 backend. THis backend 
uses RAW(16) fields as primary keys everywhere (it wasnt my choice).
THis is however giving me major headaches, as Django seems to insist on 
decoding these keys to text.

Here''s my models:
#models.py
from django.db import models
#from uuidfield import UUIDField
from django_extensions.db.fields import UUIDField


class Population(models.Model):
population_id = UUIDField(primary_key=True) 
population_name = models.CharField(max_length=400,)
population_cross = models.ForeignKey('PopulationCross')

class Meta:
managed = False
db_table = 'population'

class PopulationCross(models.Model):
population_cross_id = UUIDField(primary_key=True)  
population_cross = models.CharField(max_length=100)

class Meta:
managed = False
db_table = 'population_cross'


#--
#code
from .models import Population


x=Population.objects.all()[0]
x.population_cross
-
This last command yields:
django.utils.encoding.DjangoUnicodeDecodeError: 'utf8' codec can't decode 
byte 0xe9 in position 6: invalid continuation byte. You passed in 
'\nD\t\x025W\xe9\xc2\xe0SW\x99\x03\n\x0cc' ()

so for some reason UUIDfield presents itself as a string and it crashes the 
decode() statement internal in Django

* Using the uuid field module is not an improvement. 
* using Char fields also crashes
* using BinaryField works, but may give me misery later on.
 
I apologize if this is a known issue but I spent a day searching and found 
no solution. 
So my questions are:
* Is using BinaryField the only solution here?
* Will BinaryField put in in other trouble elsewhere?
* would the UUIDfield in dev solve my problems?

Any pointer are very welcome. As mentioned, I have no control over the 
decision to use RAW(16) as primary keys.

Sincerely
Joris

-- 
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/1afa922b-4eb5-4f28-a5c2-1d399067d18f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Bobby Mozumder]

For the Documentation, one suggestion I have is that the body font that’s more 
different from the source code font.

It looks like you’re using Roboto (a Helvetica clone) for the body text and 
Incosolota for the source code. They’re a little too similar.  Also, Roboto 
isn’t a good font for descriptive sentences and paragraphs.  It’s more of a 
short text font for titles, subheadline, and captions.

You generally don’t write long paragraphs with Helvetica, and you shouldn’t do 
that in Roboto either.

-bobby

-- 
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/DE43C262-BD64-4140-B82A-A046308F2EE2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: UUID as primary key for Oracle backend

[Joris Benschop]

replying to myself: setting the pk to a binaryfield breaks the usage of 
django-admin as this tries to force the pk into string as well (options.py 
function action_checkbox()).

-- 
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/75e71f2b-0bd9-4570-9d78-d74858af54b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[Scot Hacker]

On Tuesday, December 16, 2014 1:15:57 PM UTC-8, Sayth Renshaw wrote:
>
> With django what benefit do I get for the extra build time over Drupal or 
> Rails. 


I'd strongly contest that statement. Development time might be roughly 
equivalent to Rails (given equally experienced developers), but compared to 
Drupal? I see Drupalistas struggling to convince the platform to do the 
simplest things, on a regular basis. With Django or Rails you build what 
you need and nothing gets in your way. I just blew the minds of people in a 
predominantly Drupal-centric establishment with a Django intranet/portal 
demo I built in three weeks - they couldn't believe it. Especially for 
development of more advanced features, I'd go head-to-head with a Drupal 
dev any day of the week.

This is five years old now, and a bit long-winded, but I still stand behind 
most of it:

http://birdhouse.org/blog/2009/11/11/drupal-or-django/

./s



 

-- 
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/ff329c68-151c-41a5-a203-d66b6c8c6616%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Radomir Wojcik]

The official django doc uses this as an example (see below). Is there any 
point to storing 'FR' instead of 'Freshman" so the choice matches what is 
stored? Is it faster at all? Saves room? What about for querying the data? 
Then you have to lookup the symbol 'FR' in the tuple if someone wants to 
query by 'Freshman'. 

What is the best practice? Is it even more efficient if integers were used, 
like 1 value to represent Freshman and so on? To me it makes sense to store 
'Freshman' as 'Freshman' but I'd like to get some insight.

from django.db import models

class Student(models.Model):
FRESHMAN = 'FR'
SOPHOMORE = 'SO'
JUNIOR = 'JR'
SENIOR = 'SR'
YEAR_IN_SCHOOL_CHOICES = (
(FRESHMAN, 'Freshman'),
(SOPHOMORE, 'Sophomore'),
(JUNIOR, 'Junior'),
(SENIOR, 'Senior'),
)
year_in_school = models.CharField(max_length=2,
  choices=YEAR_IN_SCHOOL_CHOICES,
  default=FRESHMAN)

def is_upperclass(self):
return self.year_in_school in (self.JUNIOR, self.SENIOR)

-- 
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/e0a71f13-1541-437b-a7b9-24c06f08c7e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Carl Meyer]

Hi Radomir,

On 12/17/2014 09:56 AM, Radomir Wojcik wrote:
> The official django doc uses this as an example (see below). Is there any 
> point to storing 'FR' instead of 'Freshman" so the choice matches what is 
> stored? Is it faster at all? Saves room? What about for querying the data? 
> Then you have to lookup the symbol 'FR' in the tuple if someone wants to 
> query by 'Freshman'. 
> 
> What is the best practice? Is it even more efficient if integers were used, 
> like 1 value to represent Freshman and so on? To me it makes sense to store 
> 'Freshman' as 'Freshman' but I'd like to get some insight.

I'm no expert on database performance (and what I do know is entirely
specific to Postgres), but I think that a shorter string will be
somewhat more efficient (both in terms of space and speed) than a longer
string, and an integer more efficient than either. However, I'd consider
worrying about that to be premature optimization, unless you have
evidence of it being a problem.

For me the two primary considerations here are:

1) It is useful to separate the database-stored value from the displayed
representation for humans, because the latter is prone to change (in a
sense this is a normalization, so the real name is only stored in one
place, not in various rows throughout your table).

2) I find some ease-of-development value in using a text slug rather
than an integer for the database-stored value, simply because it makes
database rows more readable when working with the database directly.

Carl

> from django.db import models
> 
> class Student(models.Model):
> FRESHMAN = 'FR'
> SOPHOMORE = 'SO'
> JUNIOR = 'JR'
> SENIOR = 'SR'
> YEAR_IN_SCHOOL_CHOICES = (
> (FRESHMAN, 'Freshman'),
> (SOPHOMORE, 'Sophomore'),
> (JUNIOR, 'Junior'),
> (SENIOR, 'Senior'),
> )
> year_in_school = models.CharField(max_length=2,
>   choices=YEAR_IN_SCHOOL_CHOICES,
>   default=FRESHMAN)
> 
> def is_upperclass(self):
> return self.year_in_school in (self.JUNIOR, self.SENIOR)
> 

-- 
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/5491B9D3.3020706%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: How to set up a junction table in Django

[Tim Chase]

On 2014-12-17 06:34, Ben Gorman wrote:
> Notice the NULL value. This basically says "Game 2" consists of
> player 2 *and one undetermined* player. This functionality is what
> I need to replicate in Django. This is what I tried.
> 
> Models.py
> 
> class Player(models.Model):
> player_name = models.CharField(max_length=60)
> class Game(models.Model):
> players = models.ManyToManyField(Player, blank=True)
> game_date = models.DateField(null=True, blank=True)
> 
> But with this setup I can't seem to replicate the functionality I
> described above. How do I accomplish this?

Sounds like you want to use the "through" property of a ManyToMany
field¹, something like

class Player(models.Model):
  # ...

class Game(models.Model):
  # ...
  players = models.ManyToMany(Player, through="PlayerGame")

class PlayerGame(models.Model):
  player = models.ForeignKey(Player)
  game = models.ForeignKey(Game, blank=True, null=True)
  # possible other attributes of a PlayerGame


-tkc

¹
https://docs.djangoproject.com/en/1.7/ref/models/fields/#django.db.models.ManyToManyField.through








.

-- 
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/20141217111901.70140441%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Radomir Wojcik]

>
> Thanks for the insight, I'm on the same page as you.
>
>
My only real concern is that I will have to  use a function, such as this 
one to get the human readable version of the stored data, then you need to 
lookup the value from the dict. And if you're doing querying on that object 
using key words, you have to query based on the human readable names, so 
that will cost you to look them all up every time and do a like SQL query 
or contains every time.

def school_year_to_dict():
return dict((x, y) for x, y in YEAR_IN_SCHOOL_CHOICES)


-- 
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/4aff74b9-b684-4510-aa3a-95259c13f786%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Carl Meyer]

On 12/17/2014 11:23 AM, Radomir Wojcik wrote:
>
> Thanks for the insight, I'm on the same page as you.
>
> My only real concern is that I will have to  use a function, such as this 
> one to get the human readable version of the stored data, then you need to 
> lookup the value from the dict. And if you're doing querying on that object 
> using key words, you have to query based on the human readable names, so 
> that will cost you to look them all up every time and do a like SQL query 
> or contains every time.
> 
> def school_year_to_dict():
> return dict((x, y) for x, y in YEAR_IN_SCHOOL_CHOICES)

Django will actually attach a helper method to your model for this; see
https://docs.djangoproject.com/en/1.7/ref/models/instances/#django.db.models.Model.get_FOO_display

If you're doing keyword-based searching and worried about performance,
you'll want to index all the queryable fields into a search engine
(Elasticsearch, Solr) or a full-text-search-indexed field in Postgres
anyway, so the lookup from slug/id to display name only happens at
indexing time, not on every search.

Carl

-- 
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/5491CDFD.8070005%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Radomir Wojcik]

>
> So to answer my own question, you wouldn't use the short version in the db if 
> you plan to do like/contains queries on them. Correct me if I'm wrong.
>
>
Unless I plan to use haystack later and index the human readable form 
later. I think I understand now, 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+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/ca539494-3243-41c0-bd28-23587a28e966%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Carl Meyer]

On 12/17/2014 11:52 AM, Radomir Wojcik wrote:
>
> So to answer my own question, you wouldn't use the short version in the db if 
> you plan to do like/contains queries on them. Correct me if I'm wrong.

True. I don't think I've ever seen a case where a field had choices and
I also wanted to do like/contains queries on it. If a field has choices
set, it's likely that a more useful way to let a user search on that
field would be a fixed-choices filter rather than a keyword search.

> Unless I plan to use haystack later and index the human readable form 
> later. I think I understand now, thanks 

Right, the exception to the above would be when the value of this field
is just one field feeding into a larger keyword search on the whole
object -- and in that case I wouldn't ever do like/contains on the
original field, I'd feed its human readable form into a full text search
engine.

Carl

-- 
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/5491D23B.1050502%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Alan Hicks]

You might want to try using a many to one relationship, it adds a table 
lookup but offers flexibility where the data is in the database instead 
of the application and for large data sets can be much faster.  It's 
also good database normalization practice.


class StudentType(Models.Model):
short_name = models.CharField(max_length=2)
name = models.CharField(max_length=30)

class  Student(models.Model):
student_type = models.ForeignKey(StudentType)

It's good to learn all the different ways of doing things because each 
project is different and can benefit from either choice.  For example a 
traditional normalized database such as PostgreSQL offers many benefits, 
whereas NoSQL used in Big Data is the opposite and also offers many 
benefits.


https://docs.djangoproject.com/en/1.7/topics/db/models/#many-to-one-relationships
http://en.wikipedia.org/wiki/Database_normalization
https://en.wikipedia.org/wiki/PostgreSQL
https://en.wikipedia.org/wiki/NoSQL

Alan

On 17/12/2014 16:56, Radomir Wojcik wrote:

The official django doc uses this as an example (see below). Is there
any point to storing 'FR' instead of 'Freshman" so the choice matches
what is stored? Is it faster at all? Saves room? What about for querying
the data? Then you have to lookup the symbol 'FR' in the tuple if
someone wants to query by 'Freshman'.

What is the best practice? Is it even more efficient if integers were
used, like 1 value to represent Freshman and so on? To me it makes sense
to store 'Freshman' as 'Freshman' but I'd like to get some insight.

fromdjango.dbimportmodels


class  Student(models.Model):
 FRESHMAN  =  'FR'
 SOPHOMORE  =  'SO'
 JUNIOR  =  'JR'
 SENIOR  =  'SR'
 YEAR_IN_SCHOOL_CHOICES  =  (
 (FRESHMAN,  'Freshman'),
 (SOPHOMORE,  'Sophomore'),
 (JUNIOR,  'Junior'),
 (SENIOR,  'Senior'),
 )
 year_in_school  =  models.CharField(max_length=2,
   choices=YEAR_IN_SCHOOL_CHOICES,
   default=FRESHMAN)

 def  is_upperclass(self):
 return  self.year_in_school  in  (self.JUNIOR,  self.SENIOR)

--
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/e0a71f13-1541-437b-a7b9-24c06f08c7e5%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
Persistent Objects Ltd
128 Lilleshall Road
Morden SM4 6DR

The Home of Lasting Solutions

Mobile: 079 3030 5004
Tel:020 8544 5292
Web:p-o.co.uk
Skype:  alan-hicks-london
Personal blog https://plus.google.com/+AlanHicksLondon
Company blog https://plus.google.com/+PoCoUkLondon/posts
LinkedIn https://uk.linkedin.com/in/alanhickslondon/
GitHub https://github.com/alan-hicks

--
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/5491D335.9070502%40p-o.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[llanitedave]

On Tuesday, December 16, 2014 8:12:54 AM UTC-8, 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 
>
>
Count me with those who generally like the new layout.  The main page looks 
a little sparser on a large screen, but the documentation pages make much 
better use of space.  I think the fonts are just fine.  My main suggestion 
would be to use slightly more background contrast with the right-hand side 
bar and the code blocks.  The contrast difference is subtle enough to not 
be clear about where the boundaries are unless you're focusing directly on 
them, but noticeable enough to be distracting when you're trying to 
concentrate on content.,  

-- 
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/8aabe84a-1ee0-4d05-97bf-b37f8e81c8cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Carsten Fuchs]

Hi all,

Am 17.12.2014 um 20:36 schrieb llanitedave:

Count me with those who generally like the new layout.  The main page
looks a little sparser on a large screen, but the documentation pages
make much better use of space.  I think the fonts are just fine.  My
main suggestion would be to use slightly more background contrast with
the right-hand side bar and the code blocks.  The contrast difference is
subtle enough to not be clear about where the boundaries are unless
you're focusing directly on them, but noticeable enough to be
distracting when you're trying to concentrate on content.,


+1, this is exactly my impression and opinion as well!  :-)

Many thanks to everyone for their great work!

Best regards,
Carsten

--
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/5491DCA9.7000109%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

Re: eCommerce Search

['werefrog' via Django users]

Hi John,

You might want to search for django+faceted+search. Is it what you're 
looking for?


Best regards


Le 17/12/2014 16:20, John Rodkey a écrit :

Hi All, I apologize if this has been answered, but what is the best way to
search/query a model based on filters.

For example, say we are setting up a shoe site. What is the best way to
allow customers to search for shoes by brand, color, size, and/or price.  I
would prefer to make these dropdowns in the templates, I'm just not sure
how to build this functionality in the view.

I would appreciate any direction.



--
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/5491E7B0.1060100%40yahoo.fr.
For more options, visit https://groups.google.com/d/optout.

Re: eCommerce Search

[John Rodkey]

Yes, that is what I'm looking for.  I'm new to the Django world and was 
curious if there is already a good existing package.  I will search for 
django faceted search.

On Wednesday, December 17, 2014 2:30:13 PM UTC-6, werefrog wrote:
>
> Hi John, 
>
> You might want to search for django+faceted+search. Is it what you're 
> looking for? 
>
> Best regards 
>
>
> Le 17/12/2014 16:20, John Rodkey a écrit : 
> > Hi All, I apologize if this has been answered, but what is the best way 
> to 
> > search/query a model based on filters. 
> > 
> > For example, say we are setting up a shoe site. What is the best way to 
> > allow customers to search for shoes by brand, color, size, and/or price. 
>  I 
> > would prefer to make these dropdowns in the templates, I'm just not sure 
> > how to build this functionality in the view. 
> > 
> > I would appreciate any direction. 
> > 
>
>

-- 
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/d2097d0d-7a73-4910-9382-8136d58a05d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: eCommerce Search

[Jonathan Baker]

Also, check out: https://github.com/alex/django-filter

On Wed, Dec 17, 2014 at 2:11 PM, John Rodkey  wrote:
> Yes, that is what I'm looking for.  I'm new to the Django world and was
> curious if there is already a good existing package.  I will search for
> django faceted search.
>
>
> On Wednesday, December 17, 2014 2:30:13 PM UTC-6, werefrog wrote:
>>
>> Hi John,
>>
>> You might want to search for django+faceted+search. Is it what you're
>> looking for?
>>
>> Best regards
>>
>>
>> Le 17/12/2014 16:20, John Rodkey a écrit :
>> > Hi All, I apologize if this has been answered, but what is the best way
>> > to
>> > search/query a model based on filters.
>> >
>> > For example, say we are setting up a shoe site. What is the best way to
>> > allow customers to search for shoes by brand, color, size, and/or price.
>> > I
>> > would prefer to make these dropdowns in the templates, I'm just not sure
>> > how to build this functionality in the view.
>> >
>> > I would appreciate any direction.
>> >
>>
> --
> 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/d2097d0d-7a73-4910-9382-8136d58a05d6%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Jonathan D. Baker
Developer
http://jonathandbaker.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/CAPMFOb7q0vxgApt6RfXKj2%3DvJWDe2YcRQ77Kh6p4brJz8Kb_pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any benefit in storing shorter strings or numbers to represent data for a choice char field?

[Radomir Wojcik]

Thanks Carl, I wasn't aware of that function, that works :)  Sometimes 
normalization can just get you in trouble, slow things down.  My question 
was mainly regarding the efficiency in terms of storage, and how you query 
that if you store the short version.  I would not consider dividing the 
data up into more models at the time.  I would use something like haystack 
with elasticsearch to index the human readable names if I needed them and 
that display function is a life saver. Thanks all.

On Wednesday, 17 December 2014 11:56:08 UTC-5, Radomir Wojcik wrote:
>
> The official django doc uses this as an example (see below). Is there any 
> point to storing 'FR' instead of 'Freshman" so the choice matches what is 
> stored? Is it faster at all? Saves room? What about for querying the data? 
> Then you have to lookup the symbol 'FR' in the tuple if someone wants to 
> query by 'Freshman'. 
>
> What is the best practice? Is it even more efficient if integers were 
> used, like 1 value to represent Freshman and so on? To me it makes sense to 
> store 'Freshman' as 'Freshman' but I'd like to get some insight.
>
> from django.db import models
>
> class Student(models.Model):
> FRESHMAN = 'FR'
> SOPHOMORE = 'SO'
> JUNIOR = 'JR'
> SENIOR = 'SR'
> YEAR_IN_SCHOOL_CHOICES = (
> (FRESHMAN, 'Freshman'),
> (SOPHOMORE, 'Sophomore'),
> (JUNIOR, 'Junior'),
> (SENIOR, 'Senior'),
> )
> year_in_school = models.CharField(max_length=2,
>   choices=YEAR_IN_SCHOOL_CHOICES,
>   default=FRESHMAN)
>
> def is_upperclass(self):
> return self.year_in_school in (self.JUNIOR, self.SENIOR)
>
>

-- 
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/2f8b67d6-8e98-460a-b7ee-210aef311ce6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Ben Gorman]

Awesome job to everyone involved.  I'm a fan of the (much needed) 
improvements to the website.

On Tuesday, December 16, 2014 10:12:54 AM UTC-6, 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/91cc3dc6-f22e-4541-9d25-e4f1623f71ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[John Schmitt]

Looks nice to me.

Pardon me please for being naive, but will the fonts, colours, and layouts be 
ported to the Django app itself?

That is, will the new layout and colour scheme be available to my Django 1.7 
app if I were to do the following?

$ pip install Django --upgrade

John

-- 
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/20141217224014.GB11643%40mediapc.snapdragonfly.net.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Carl Meyer]

Hi John,

On 12/17/2014 03:40 PM, John Schmitt wrote:
> Looks nice to me.
> 
> Pardon me please for being naive, but will the fonts, colours, and layouts be 
> ported to the Django app itself?
> 
> That is, will the new layout and colour scheme be available to my Django 1.7 
> app if I were to do the following?
> 
> $ pip install Django --upgrade

No, none of these changes affect the Django codebase. The Django admin
is the only part of Django that has a layout or color scheme, and it is
not related to the Django website.

Carl

-- 
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/549206FA.7000300%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Loving the new site / Performance and Optimization

[Russell Keith-Magee]

Hi JJ,

For archival purposes, I've just deleted your post from the Django Users
archive.

Pete and the team at Lincoln Loop are long standing, highly respected
members of the Django community, and you've just done them a huge
disservice.

The very first page in the "High performance Django" book contains the text:

"""
Sharing your copy to the world on public sites, torrents, etc. is not fair
use. Please don’t do it.
"""

So, *of course* that meant you had full permission to send this
PDF to a mailing list of 22000 people. 

Unfortunately, there's nothing I can do to retrieve the book from the 22000
email boxes to which it has already been delivered - the damage has been
done.

Please don't do this again.

Yours,
Russ Magee %-)

On Thu, Dec 18, 2014 at 2:31 AM, JJ Zolper  wrote:

> My fellow Django developers,
>
> First off I just want to say I'm really happy with the new design of our
> website. I think by modernizing our face we will attract new individuals
> into programming and our beautiful web framework Django. My sense from the
> community is that we are very welcoming to those who are new to learning
> how to build websites, and I think this makes us significantly stronger. I
> know from my own personal growth that the Django community has been pivotal
> in helping me attain my dreams as I am nearing the launch of my first
> website, Athletes United, and so I want to give back by bringing new ideas
> that I think will help others grow in their journey just like those before
> me have helped me grow and prosper.
>
> Secondly, I think that by expanding our documentation on Performance and
> Optimization, we will further strengthen our community and continue to
> make our community more well rounded. As an individual who had to teach
> himself how to code and build websites, my feelings stem from the need I
> see in helping others rapidly and effectively learn how to deploy their
> hard work. To accomplish this I would like to suggest to you all today the
> possibility of refactoring and then potentially including the material and
> guidance within Peter Baumgartner & Lincoln Loop's book High Performance
> Django. For reference their Kickstarter can be found here:
>
> https://www.kickstarter.com/projects/1704706557/high-performance-django
>
> I have also attached a copy that I have as a backer.
>
> Potentially another document with a wealth of information we could factor
> in would be Instagram's engineering blog:
>
>
> http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances
>
> I believe we have a great start as seen here:
>
> https://docs.djangoproject.com/en/1.7/topics/performance/
>
> But I would like to stand up and push for further discussions to be had to
> bring about, in my mind, a much stronger support for the final step in a
> django developer's journey. I certainly understand solutions can be on a
> case by case basis but I think supplementing what we currently provide will
> only benefit us.
>
> I think by banding together we can lessen the load on each individual and
> attain an even more comprehensive home on our beautiful djangoproject.com.
>
> Thank you very much for your time today and I hope to hear from anyone who
> wishes to discuss this further soon.
>
> JJ Zolper
>
> --
> 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/a76a7bf2-45af-4ff6-80c6-2117c9104c73%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/CAJxq848KkOvvwUp00n_dvsWS9COT%3D9izSe8eYAuECL6%2BV2Oziw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[John-Scott]

Thanks for your replies Markus!

I've added a ticket here https://code.djangoproject.com/ticket/24016

On Wednesday, December 17, 2014 10:47:26 AM UTC-5, Markus Holtermann wrote:
>
> I agree, a general "here's how you should do it" section in the docs 
> should be added. Would you mind opening a ticket on 
> https://code.djangoproject.com/ where you state the problem (e.g. link to 
> this discussion). Thanks.
>
> /Markus
>
> On Wednesday, December 17, 2014 6:01:05 AM UTC+1, John-Scott wrote:
>>
>> 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/9ac3c6c9-b36b-450a-9527-687623c1165c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Devils advocate question

[James Schneider]

As a reformed PHP and Drupal developer, I can say with 100% certainty that
trying to crowbar Drupal (or any CMS) in to performing actions that are
outside of the built-in core functionality is a nightmare at best. I wrote
half a dozen custom modules (~6K SLOC), and at least 30% of that was wasted
code that simply overrode the default behavior of the CMS. I grew weary of
playing whack-a-mole with built-in constraints, and hit a point of
diminishing returns where I spent more time fighting with the Drupal
internals than adding needed functionality.

Drupal is a relatively good CMS and has regular updates with an active
community. If your planned app fits within the CMS model, even with a few
tweaks from 3rd party modules, you can be up/running with a smaller amount
of raw developer effort if you keep within their sandbox. The biggest draw
for me at the time was not needing to build the HTML presentation layer and
letting Drupal handle the formatting using their theme system. As my
requirements grew outside of the CMS box, it became a hindrance. Obviously
I don't have that [dis]advantage with Django, and even the built-in admin
portal would likely cause me the same grief, so I'm rolling my own custom
HTML templates (which for me takes more time than the functional code
underneath). Authentication/authorization was another pain point with
Drupal, as it is much more tightly integrated into their core. I'm rolling
a custom auth solution for Django as well to meet my requirements. Don't
even get me started on the ridiculous amount of expensive SQL queries that
were run per request...almost everything in a CMS comes from the database.
I needed APC caching just to have a usable site for 20 concurrent users.
PHP just feels dirty, especially with inconsistent function naming schemes
using CamelCase or under_scores. Maintaining raw PHP code intertwined
inside of HTML templates is obnoxious. Django template abstraction with
tags, etc. is a much cleaner way to go, and keeps you honest in terms of
littering inside of your HTML templates.

In terms of development time, I can have a blog running in Drupal in 10-15
minutes with a custom theme. The equivalent in Django would probably be a
day or two's worth of work at best assuming that you already know what you
are doing and are awesome with HTML. There are probably Django packages
that would shorten that time, though. However, trying to build a pizza
ordering system in Drupal would require psychological therapy and probably
never be finished, but the raw logic of how to do it can be a day or two's
work in Django (depending on how good your HTML skills are). You might even
be able to do that in the admin and skip the HTML all together. Development
and time to production are heavily dependent on your skill set and
available resources for either product. If you don't know Python/HTML,
don't expect a fully working application in the blink of an eye.

Keep in mind that Drupal is a CMS, with an obvious bias towards CMS-type
functionality (and is designed to be an almost entirely point and click
solution). Django is a lower-level framework that provides a toolkit to
build whatever you want (including not being limited to just rendering
HTML). Think of Django as a work truck loaded with construction tools and
lumber, and Drupal as a pre-fabricated house that just gets placed on the
foundation. You can pick the color of the house, but that's it, although,
for some people, a blue house is all they need. It's hard to compare the
two as they have different uses in mind. Not to mention that Python is a
much cleaner language in many respects, most notably for syntax and memory
management.

As mentioned before, Rails is similar to Django with the big exception
being written in Ruby, rather than Python. Not sure what other magic secret
sauce they include, but I found anything with Ruby tends to be more magical
than pragmatic in my limited experience with it when I considered it when I
chose the Django path.


HTH,

-James



On Wed, Dec 17, 2014 at 8:38 AM, Scot Hacker  wrote:
>
>
>
> On Tuesday, December 16, 2014 1:15:57 PM UTC-8, Sayth Renshaw wrote:
>>
>> With django what benefit do I get for the extra build time over Drupal or
>> Rails.
>
>
> I'd strongly contest that statement. Development time might be roughly
> equivalent to Rails (given equally experienced developers), but compared to
> Drupal? I see Drupalistas struggling to convince the platform to do the
> simplest things, on a regular basis. With Django or Rails you build what
> you need and nothing gets in your way. I just blew the minds of people in a
> predominantly Drupal-centric establishment with a Django intranet/portal
> demo I built in three weeks - they couldn't believe it. Especially for
> development of more advanced features, I'd go head-to-head with a Drupal
> dev any day of the week.
>
> This is five years old now, and a bit long-winded, but I still stand
> behind most of it:
>
> http://birdhouse.org/blog/2009/1

Re: Devils advocate question

[Mario Gudelj]

Deploying your Django site doesn't have to be that painful. You can do it
in a single command with https://github.com/gcollazo/Fabulous. It'll take
you about an hour to have a full stack running with a bit of tweaking.

On 18 December 2014 at 11:11, James Schneider 
wrote:
>
> As a reformed PHP and Drupal developer, I can say with 100% certainty that
> trying to crowbar Drupal (or any CMS) in to performing actions that are
> outside of the built-in core functionality is a nightmare at best. I wrote
> half a dozen custom modules (~6K SLOC), and at least 30% of that was wasted
> code that simply overrode the default behavior of the CMS. I grew weary of
> playing whack-a-mole with built-in constraints, and hit a point of
> diminishing returns where I spent more time fighting with the Drupal
> internals than adding needed functionality.
>
> Drupal is a relatively good CMS and has regular updates with an active
> community. If your planned app fits within the CMS model, even with a few
> tweaks from 3rd party modules, you can be up/running with a smaller amount
> of raw developer effort if you keep within their sandbox. The biggest draw
> for me at the time was not needing to build the HTML presentation layer and
> letting Drupal handle the formatting using their theme system. As my
> requirements grew outside of the CMS box, it became a hindrance. Obviously
> I don't have that [dis]advantage with Django, and even the built-in admin
> portal would likely cause me the same grief, so I'm rolling my own custom
> HTML templates (which for me takes more time than the functional code
> underneath). Authentication/authorization was another pain point with
> Drupal, as it is much more tightly integrated into their core. I'm rolling
> a custom auth solution for Django as well to meet my requirements. Don't
> even get me started on the ridiculous amount of expensive SQL queries that
> were run per request...almost everything in a CMS comes from the database.
> I needed APC caching just to have a usable site for 20 concurrent users.
> PHP just feels dirty, especially with inconsistent function naming schemes
> using CamelCase or under_scores. Maintaining raw PHP code intertwined
> inside of HTML templates is obnoxious. Django template abstraction with
> tags, etc. is a much cleaner way to go, and keeps you honest in terms of
> littering inside of your HTML templates.
>
> In terms of development time, I can have a blog running in Drupal in 10-15
> minutes with a custom theme. The equivalent in Django would probably be a
> day or two's worth of work at best assuming that you already know what you
> are doing and are awesome with HTML. There are probably Django packages
> that would shorten that time, though. However, trying to build a pizza
> ordering system in Drupal would require psychological therapy and probably
> never be finished, but the raw logic of how to do it can be a day or two's
> work in Django (depending on how good your HTML skills are). You might even
> be able to do that in the admin and skip the HTML all together. Development
> and time to production are heavily dependent on your skill set and
> available resources for either product. If you don't know Python/HTML,
> don't expect a fully working application in the blink of an eye.
>
> Keep in mind that Drupal is a CMS, with an obvious bias towards CMS-type
> functionality (and is designed to be an almost entirely point and click
> solution). Django is a lower-level framework that provides a toolkit to
> build whatever you want (including not being limited to just rendering
> HTML). Think of Django as a work truck loaded with construction tools and
> lumber, and Drupal as a pre-fabricated house that just gets placed on the
> foundation. You can pick the color of the house, but that's it, although,
> for some people, a blue house is all they need. It's hard to compare the
> two as they have different uses in mind. Not to mention that Python is a
> much cleaner language in many respects, most notably for syntax and memory
> management.
>
> As mentioned before, Rails is similar to Django with the big exception
> being written in Ruby, rather than Python. Not sure what other magic secret
> sauce they include, but I found anything with Ruby tends to be more magical
> than pragmatic in my limited experience with it when I considered it when I
> chose the Django path.
>
>
> HTH,
>
> -James
>
>
>
> On Wed, Dec 17, 2014 at 8:38 AM, Scot Hacker 
> wrote:
>>
>>
>>
>> On Tuesday, December 16, 2014 1:15:57 PM UTC-8, Sayth Renshaw wrote:
>>>
>>> With django what benefit do I get for the extra build time over Drupal
>>> or Rails.
>>
>>
>> I'd strongly contest that statement. Development time might be roughly
>> equivalent to Rails (given equally experienced developers), but compared to
>> Drupal? I see Drupalistas struggling to convince the platform to do the
>> simplest things, on a regular basis. With Django or Rails you build what
>> you need and nothing gets in your