Re: How to install psycopg2 using Pip?

[Dow Street]

My understanding is that psycopg2 looks for some postgres files during the 
install.  If you have postgres already installed on the same box, you should be 
able to resolve this problem by adding the postgres folder to your PATH 
environment variable before running 'pip install psycopg2'.  The syntax for 
modifying the PATH might differ a little based on the operating system, but it 
would normally be something like this:

PATH=$PATH:/Library/PostgreSQL/9.1/bin

Here postgres is installed at /Library/PostgreSQL/9.1/bin, but it might be in a 
different location on your machine.  As Fabio mentioned, if you do not have 
postgres installed on the same machine you may be able to add the development 
libraries for your OS and get it to work.

One note about modifying the PATH - due to the way virtualenv can adjust PATH 
contents you may need to add the postgres folder to the PATH after the 
virtualenv is activated.  (not sure about this ...)

Hope that helps!



On Jun 4, 2014, at 6:33 AM, Fabio Caritas Barrionuevo da Luz  
wrote:

> 
> If Ubuntu 12.04 or higher
> 
> do:
> 
> sudo apt-get install libpq-dev
> 
> 
> 
> 
> Em quinta-feira, 24 de março de 2011 12h01min43s UTC-3, Andre Lopes escreveu:
> Hi,
> This question is not directly related with Django, but with Python.
> 
> I have installed "virtualenv" to have a virtual environment. Now I
> need to instal "psycopg2" in my virtual environment, but I have not
> successfully installed.
> 
> My steps:
> 
> [quote]
> pip install
> http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.tar.gz#md5=24f4368e2cfdc1a2b03282ddda814160
> [/quote]
> 
> And I got this message with an error:
> 
> [quote]
> Downloading/unpacking
> http://pypi.python.org/packages/source/p/psycopg2/psycopg2
> -2.4.tar.gz#md5=24f4368e2cfdc1a2b03282ddda814160
>   Downloading psycopg2-2.4.tar.gz (607Kb): 607Kb downloaded
>   Running setup.py egg_info for package from
> http://pypi.python.org/packages/sou
> 
> rce/p/psycopg2/psycopg2-2.4.tar.gz#md5=24f4368e2cfdc1a2b03282ddda814160
> Error: pg_config executable not found.
> 
> Please add the directory containing pg_config to the PATH
> or specify the full executable path with the option:
> 
> python setup.py build_ext --pg-config 
> /path/to/pg_config build ...
> 
> or with the pg_config option in 'setup.cfg'.
> Complete output from command python setup.py egg_info:
> running egg_info
> 
> creating pip-egg-info\psycopg2.egg-info
> 
> writing pip-egg-info\psycopg2.egg-info\PKG-INFO
> 
> writing top-level names to 
> pip-egg-info\psycopg2.egg-info\top_level.txt
> 
> writing dependency_links to 
> pip-egg-info\psycopg2.egg-info\dependency_links.txt
> 
> writing manifest file 'pip-egg-info\psycopg2.egg-info\SOURCES.txt'
> 
> warning: manifest_maker: standard file '-c' not found
> 
> Error: pg_config executable not found.
> 
> 
> Please add the directory containing pg_config to the PATH
> 
> or specify the full executable path with the option:
> 
> 
> python setup.py build_ext --pg-config /path/to/pg_config 
> build ...
> 
> 
> or with the pg_config option in 'setup.cfg'.
> 
> 
> Command python setup.py egg_info failed with error code 1
> Storing complete log in C:\Documents and Settings\anlopes\Application
> Data\pip\p
> ip.log
> [/quote]
> 
> My question:
> 
> How can I tell to "pip" where is my pg_config?
> 
> Best Regards,
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+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/772ac1dc-e7c2-415c-bc6e-21a1e5b0ec4c%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/44FC535C-1446-4673-8662-906D54E3C247%40prodigy.net.
For more options, visit https://groups.google.com/d/optout.

Re: IndentationError :Unexpected Indent

[Dow Street]

Based on the code below it looks like your indentation is off for def 
was_published recently code block (i.e. 3 spaces instead of 4).  If that does 
not solve the problem, you might also check to ensure that you're not mixing 
tabs and spaces when indenting.  Depending on your environment that can lead to 
some confusing errors.  For example, if you have a tab in one line, and 
multiple spaces in the next line (of the same code block), in your editor it 
might appear visually that the indentation is the same, but the interpreter may 
treat them differently.

Different folks prefer tabs vs. spaces, but the key is to be consistent.  
google's style guide calls for 4 spaces:

https://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation

R,
Dow


On Apr 28, 2014, at 6:54 AM, Rene Zelaya  wrote:

> Ditto from what Andreas said - Python is very sensitive to indentation.  If 
> the method 'was_published_recently' is part of the Poll model, then there 
> should be the same amount of indentations before 'def was_published...' as 
> for the 'def __unicode__' method.  Then, for uniformity's sake (even though 
> it is technically not necessary), the 'return self.pub_date...' line should 
> also have the same number of indents FROM the indent where the 'def 
> was_published...' method line starts (in this case 3), like so:
> 
> class Poll(models.Model):
> question = models.CharField(max_length=200)
> pub_date = models.DateTimeField('date published')
> 
> def __unicode__(self):  
> return self.question
> 
>def was_published_recently (self):
>   return self.pub_date > = timezone.now() - datetime.timedelta(days=1)
> 
> This is to indicate it is IN the 'was_published_recently' method.
> Cheers.
> 
> 
> On Monday, April 28, 2014 1:55:27 AM UTC-4, Kelvin Mwangi wrote:
>  I have been following up on the tutorial on Python version 1.6 and I got 
> stuck at an indentation error I can't seem to debug. Its under the first 
> tutorial of creating Django application and I modified my polls\models.py 
> file to look like this;
> 
> from django.db import models
> import datetime
> from django.utils import timezone
> 
> class Poll(models.Model):
> question = models.CharField(max_length=200)
> pub_date = models.DateTimeField('date published')
> def __unicode__(self):  
> return self.question
>   def was_published_recently (self):
>   return self.pub_date > = timezone.now() - 
> datetime.timedelta(days=1)
> 
> class Choice(models.Model):
> poll = models.ForeignKey(Poll)
> choice_text = models.CharField(max_length=200)
> votes = models.IntegerField(default=0)
>   def __unicode__(self):  
> return self.choice_text 
> 
> I keep getting an error at that line that starts with "def 
> was_published_recently.." and can't seem to debug the error. Can anyone 
> kindly help me here? I'm stuck. :( 
> 
> 
> -- 
> 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/725f3014-2e81-4af5-9ccb-41cc696191b9%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/913E6FEB-A50B-4BD3-93A5-23200C539D58%40prodigy.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django Data Visualization

[Dow Street]

I'm not familiar with django-boxes, but one architectural question is whether 
you want to render the graphs on the server (e.g. python) or in the browser 
(e.g. javascript).

If you render on the server, you could use something like matplotlib (python) 
to draw your graphs, and then push those images to the client.  You can make 
some pretty nice graphs with matplotlib, but a disadvantage of this approach is 
that it is difficult to make the graphs interactive.  The more common approach 
these days seems to be to push just the data behind your graphs to the browser 
(e.g. using JSON), and then draw the graphs on the client side using 
javascript.  d3js is a great library for drawing interactive graphs in SVG, 
and/or you could use HTML5 canvas elements.

Good luck!

Dow


On Dec 13, 2013, at 3:14 AM, +Emmanuel  wrote:

> I am looking at creating a Django data visualization app, an idea that 
> closely resembles this: 
> http://preview.jumpstartthemes.com/canvas-admin/chart-morris.html
> The idea is to have 'regions' that are database controlled, pulling data from 
> the database and presenting it in user friendly charts and graphs. Can I use 
> django-boxes for this? How best should I approach this?
> 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/cbed0af4-8ae9-4766-a88d-2ce9f190f321%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+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/F81F2A7C-140C-4405-99B2-F08EB169B5E3%40prodigy.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: having trouble with virtualenvwrapper - need to run 'source ~/.profile' every time.

[Dow Street]

And just a reminder that you can certainly use virtualenv without 
virtualenvwrapper.  Every env you create with virtualenv will have a script to 
activate that env located at envname/bin/activate.  For example:  

Open your shell, cd to the desired directory, and create a new env:

$ virtualenv testenv
New python executable in testenv/bin/python
Installing setuptools.done.
Installing pip...done.

Activate the env:

$ . testenv/bin/activate
(testenv)$

Note that the prompt changed and is now pre-pended by the env name.

Deactivate the env:

(testenv)$ deactivate
$ 

The prompt changes back - env is deactivated.

R,
Dow


On Oct 16, 2013, at 2:32 PM, Bill Freeman  wrote:

> virtualenv is, indeed, great stuff, and is unlikely to be your problem.
> 
> 
> On Wed, Oct 16, 2013 at 3:24 PM, J. Paskaruk  wrote:
> I will keep that in mind for sure - I'm always aware that there are little 
> subtleties like that all around me, waiting to trip me up, so when someone 
> explains one to me, I cleave to the info. I'm pretty paranoid about this kind 
> of thing to begin with, which is why I removed it from the one when I added 
> it to the other - if it only needs to be there once, then having it there 
> twice is just stupidity, unless there is a demonstrable reason to do so. 
> 
> I'm kinda suspicious of virtualenv in the first place because of this, but 
> the sales pitch by that nice young man, Simeon Whatsisname, convinced me that 
> it was a good idea to get a handle on it.
> 
> 
> On Wed, Oct 16, 2013 at 12:51 PM, Bill Freeman  wrote:
> Not strictly true.  .bashrc will get run again in a sub-shell.  For example, 
> in your shell, you run a command, and that command is a shell script.  A new 
> shell is started to run that script.  It inherits your environment variables. 
>  But it also runs .bashrc.  That's usually not a problem, but there are 
> corner cases where it is, so it's worth taking a little care in writing a 
> .bashrc file.
> 
> 
> On Wed, Oct 16, 2013 at 1:40 PM, J. Paskaruk  wrote:
> Ahh k. I took it out of .profile entirely and put it in .bashrc, so it should 
> only be run the once. I'm the only significant user of this computer. Cheers!
> 
> 
> On Wed, Oct 16, 2013 at 11:45 AM, Bill Freeman  wrote:
> What I mean by "I don't know about sourceing virtualenvwrapper.sh" is that I 
> don't know, and don't have the inclination to research, whether, having 
> sourced the file in a shell, you should avoid sourcing it again in a 
> sub-shell.
> 
> What I mean by guard variables is that you could, at the end of your .bashrc, 
> export a variable that is unlikely to clash with the variables of other 
> systems, e.g.;
> 
> export BASHRC_HAS_ALREADY_BEEN RUN
> 
> And earlier in the file test the variable to guard against redoing the things 
> that should not be redone.
> 
> if [ "$BASHRC_HAS_ALREADY_BEEN RUN" -ne "1" ]; then
># Put stuff that shouldn't be done twice here
> fi
> 
> 
> On Wed, Oct 16, 2013 at 12:24 PM, J. Paskaruk  wrote:
> That's the one, thank you so much! I saw in the comments of .profile that it 
> would not be read if there was a .bashrc file present, so my next step was 
> creating that file and putting those lines in it, but I'm very afraid of 
> pooching my install. Noob, like I said. :>
> 
> I have Aspergers, so I'm not clear on what you meant by "I don't know about 
> sourceing virtualenvwrapper.sh.  (Guard variables are your friend.)" - I'm 
> assuming, though, that you're referring to a security concern in this line, 
> presumably based on the idea that someone could access virtualenvwrapper.sh 
> and put malicious code in there.
> 
> If I've assessed your comment correctly, is there a good, basic tutorial on 
> {guard variables}, as well as the larger schema into which they fit? 
> Preferably one that *does* assume intelligence, but does *not* assume a lot 
> of existing knowledge on the part of the user?
> 
> 
> Whatever the case, thank you again for the new knowledge about .profile and 
> .bashrc. :>
> 
> 
> On Wed, Oct 16, 2013 at 11:14 AM, Bill Freeman  wrote:
> The file you want (assuming that your shell is bash) is .bashrc because it is 
> run every time a bash shell is started, even if it is not a login shell.
> 
> Note, however, that settings that shouldn't be done multiple times, such as 
> appending ":$HOME/bin" to the PATH, should be protected with an if so they 
> only happen once, no matter how many sub-shells you start (such as by running 
> something in parentheses), so that PATH doesn't grow without bound.  The 
> WORKON_HOME and PROJECT_HOME settings don't suffer from this problem because 
> it doesn't hurt to set them again to the same value.  I don't know about 
> sourceing virtualenvwrapper.sh.  (Guard variables are your friend.)
> 
> For some of this stuff it may also be possible 

Re: bug in multi-level multi-table inheritance?

[Dow Street]

All,

I've added a ticket for this issue:

https://code.djangoproject.com/ticket/20776

If anyone has a chance to verify that this is a bug (rather than a programming 
error on my part) I would greatly appreciate it.

Thanks!
Dow


On Jul 18, 2013, at 11:08 PM, Dow Street <dowstr...@prodigy.net> wrote:

> All,
> 
> I'm seeing some unexpected behavior when using multi-level multi-table 
> inheritance.  In the example below there are three levels in the class 
> hierarchy.  When accessing the name field (which is stored in the Level1 base 
> class) from an object in Level3, the query does not seem to walk the 
> hierarchy correctly.
> 
> Note:  I am using explicitly defined id and OneToOneFields so that I can 
> specify the db_column names (for compatibility with other legacy software 
> using the same database).  Here's the models file, followed by a console log 
> where I created test objects (in an otherwise blank database):
> 
> 
> 
> # models.py
> 
> from django.db import models
> 
> class Level1(models.Model):
>  """ Top level base class """
> 
>  level1_id = models.AutoField(primary_key=True, db_column='Level1_ID')
>  name = models.CharField(max_length=32, db_column='Name', blank=True, 
> null=True)
> 
>  class Meta:
>  db_table = 'Level1'
> 
> 
> class Level2(Level1):
>  """ Middle level class """
> 
>  level2_id = models.AutoField(primary_key=True, db_column='Level2_ID')
>  level1 = models.OneToOneField('Level1', db_column='Level1_ID', 
> parent_link=True)  # parent class
> 
>  class Meta:
>  db_table = 'Level2'
> 
> 
> class Level3(Level2):
>  """ Bottom level class """
> 
>  level3_id = models.AutoField(primary_key=True, db_column='Level3_ID')
>  level2 = models.OneToOneField('Level2', db_column='Level2_ID', 
> parent_link=True)  # parent class
> 
>  class Meta:
>  db_table = 'Level3'
> 
> 
> 
> From the manage.py shell I add two objects to an otherwise empty database:
> 
> (InteractiveConsole)
> 
> from sc_test.models import *
> 
> # add Level1 object
> top1 = Level1()
> top1.name = 'Top 1'
> top1.save()
> 
> # add Level3 object
> bot1 = Level3()
> bot1.name = 'Bot 1'
> bot1.save()
> 
> # query for Level1 objects
> l1 = Level1.objects.all()
> l1
> [, ]
> 
> # query for Level2 objects
> l2 = Level2.objects.all()
> l2
> []
> 
> # query for Level3 objects
> l3 = Level3.objects.all()
> l3
> []
> 
> # Get name of first Level1 object (looks ok)
> l1[0].name
> u'Top 1'
> 
> # Get name of second Level1 object (looks ok)
> l1[1].name
> u'Bot 1'
> 
> # First Level2 object (looks ok)
> l2[0].name
> u'Bot 1'
> 
> # First Level3 object (!! WRONG !!)
> l3[0].name
> u'Top 1'
> 
> (WRONG - expected this to return u'Bot 1')
> 
> Can anyone shed some light?  Specifically, does multi-table inheritance only 
> work with one level of subclassing?  If not, is there some syntax trick I'm 
> missing, or is this a bug in the inheritance code?
> 
> 
> Thanks,
> Dow

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

bug in multi-level multi-table inheritance?

[Dow Street]

All,

I'm seeing some unexpected behavior when using multi-level multi-table 
inheritance.  In the example below there are three levels in the class 
hierarchy.  When accessing the name field (which is stored in the Level1 base 
class) from an object in Level3, the query does not seem to walk the hierarchy 
correctly.

Note:  I am using explicitly defined id and OneToOneFields so that I can 
specify the db_column names (for compatibility with other legacy software using 
the same database).  Here's the models file, followed by a console log where I 
created test objects (in an otherwise blank database):



# models.py

from django.db import models

class Level1(models.Model):
  """ Top level base class """

  level1_id = models.AutoField(primary_key=True, db_column='Level1_ID')
  name = models.CharField(max_length=32, db_column='Name', blank=True, 
null=True)

  class Meta:
  db_table = 'Level1'


class Level2(Level1):
  """ Middle level class """

  level2_id = models.AutoField(primary_key=True, db_column='Level2_ID')
  level1 = models.OneToOneField('Level1', db_column='Level1_ID', 
parent_link=True)  # parent class

  class Meta:
  db_table = 'Level2'


class Level3(Level2):
  """ Bottom level class """

  level3_id = models.AutoField(primary_key=True, db_column='Level3_ID')
  level2 = models.OneToOneField('Level2', db_column='Level2_ID', 
parent_link=True)  # parent class

  class Meta:
  db_table = 'Level3'



>From the manage.py shell I add two objects to an otherwise empty database:

(InteractiveConsole)

from sc_test.models import *

# add Level1 object
top1 = Level1()
top1.name = 'Top 1'
top1.save()

# add Level3 object
bot1 = Level3()
bot1.name = 'Bot 1'
bot1.save()

# query for Level1 objects
l1 = Level1.objects.all()
l1
[, ]

# query for Level2 objects
l2 = Level2.objects.all()
l2
[]

# query for Level3 objects
l3 = Level3.objects.all()
l3
[]

# Get name of first Level1 object (looks ok)
l1[0].name
u'Top 1'

# Get name of second Level1 object (looks ok)
l1[1].name
u'Bot 1'

# First Level2 object (looks ok)
l2[0].name
u'Bot 1'

# First Level3 object (!! WRONG !!)
l3[0].name
u'Top 1'

(WRONG - expected this to return u'Bot 1')

Can anyone shed some light?  Specifically, does multi-table inheritance only 
work with one level of subclassing?  If not, is there some syntax trick I'm 
missing, or is this a bug in the inheritance code?


Thanks,
Dow

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Understanding an existing big web application written in Django

[Dow Street]

I also find it helpful to generate a diagram of the model relationships - e.g. 
using graph_models in django-extensions:

http://pythonhosted.org/django-extensions/



On Jun 6, 2013, at 7:06 AM, si  wrote:

> I have already existing web application code written by a someone else now I 
> need to work on it.
> So I am trying to understand the architecture of the various classes and 
> interaction. I want to know where jump in and how to understand the 
> architecture of the code.
> Urls.py seems to be a good place to start off. 
> Thanks for the suggestions. 
> 
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Bulk] Re: Template Inheritance doubt

[Dow Street]

Hi.  I'm not sure, but we may be using the terms 'parent' and 'child' 
differently (i.e. what you're calling a child I'm calling a parent?).  I have 
only used django template inheritance where a given template file has at most 
one {% extends %} tag in it - that is what I am referring to when I say 'has at 
most one parent'.  However, the base.html template (the parent) is extended by 
many different child templates (e.g. view1.html).  Is this what you are 
thinking as well?

If you want a template to inherit from multiple parents - e.g. include multiple 
{% extends %} tags - well, that is not something I have done previously (and I 
can't say whether that model is supported).  However, you can achieve 
comparable functionality (I think) by adding a layer in the inheritance 
hierarchy - for example:

base.html - has empty blocks for topbar and sidebar
topbar.html - extends base.html and contains the code for the topbar  
sidebar.html - extends topbar.html and contains the code for the sidebar
view1.html - extends sidebar.html and contains the code specific to that page

If you load the view1.html template in your view function all those {% extends 
%} tags will cause the django template engine to walk the hierarchy, starting 
from base -> topbar -> sidebar -> view1, leaving you with a single 'merged' 
html file.  At each step, if a child template has a block with the same name as 
one of the parents, the child block will overwrite the contents of the parent 
block.  Does this make sense?

(and I should note that I am by no means an expert in the django template 
processor - this is just my understanding).

R,
Dow


On May 18, 2013, at 11:12 PM, Parin Porecha  wrote:

> Dow,
> I am trying to have multiple children of the same parent. And thats why I'm 
> not able to decide which child to load. Anyways, the sidebar and topbar are 
> more or less static, so I guess there isn't much need to have separate files 
> for them. I want to have them different so that developing that section of 
> the website would be easier. In the end, I want to merge all those different 
> sections into one file and load that in my view. Can you please help me with 
> this ?
> 
> Artem,
> Yes, I get it :) Thanks!
> 
> 
> On Sat, May 18, 2013 at 9:56 PM, Artem Zinoviev  wrote:
> if you have base.html and sidebar.html, base.html file just declare {% block 
> sidebar %} section and sidebar.html make implementation of it, if you have 
> SidebarView, then you load sidebar.html and this file take all from {% 
> extends base.html %}. And if you try load base.html from SidebarView - you 
> get it :-), but {% block sidebar %} section be blank...
> 
> суббота, 18 мая 2013 г., 12:14:37 UTC+3 пользователь Parin Porecha написал:
> Hi,
> 
> I have just started to learn Django's template inheritance and I am stuck due 
> to this problem -
> In my application's 'base.html', I have defined two blocks -
> {% block topbar %}{% endblock topbar %}
> and
> {% block sidebar %}{% endblock sidebar %}
> 
> I have 2 templates - 'sidebar.html' which extends {% block sidebar %}
> and 'topbar.html' which extends {% block topbar %}
> 
> The 'sidebar.html' is also divided into further blocks which are extended by 
> other templates.
> 
> Now, my question is -
> in 'views.py', i have a view which is supposed to render the whole homepage ( 
> i.e.- including the sidebar, topbar and content ). So, which template should 
> I load in the view, so that both sidebar and topbar plus the content defined 
> in other templates gets shown ?
> because 'base.html' contains many children, I'm confused which one to load
> 
> Thanks to mattmc who tried to help me with this in IRC. Sorry, didn't get it 
> completely :)
> 
> -- 
> Regards,
> Parin Porecha
> 
> say Kifflom! and look forward to 17.09.13 !
> 
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> 
> -- 
> Regards,
> Parin Porecha
> 
> say Kifflom! and look forward to 17.09.13 !
> 
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: Template Inheritance doubt

[Dow Street]

It sounds like you are trying to have a template inherit code from multiple 
parents.  One option is to stay with a simple inheritance hierarchy where each 
child template extends at most one parent template.  If you want to use 
different code for different sub-sections of your project then just add a level 
to the hierarchy.

For example, you could add the content of topbar.html and sidebar.html into the 
topbar and sidebar blocks in the base template (i.e. inside your current topbar 
and sidebar block tags in base.html).  If a view template then extends the base 
template, but you do not want to include the topbar and sidebar code, add empty 
topbar and sidebar blocks to the view template so that the base code gets 
swapped out with an empty block.  

If you have different sections of your app and want to use different topbar and 
sidebar code in each, then add a level to your template hierarchy - something 
like:

base.html - overall site template
s1_base.html - extends base.html - put section specific topbar and sidebar code 
here
view1.html - extends s1_base.html - put view specific stuff in here

In this case you could leave empty topbar and sidebar blocks in base.html, 
adding the content to s1_base.html instead.  Or you could even have have 
view1.html extend sidebar1.html, which extends topbar1.html, which extends 
base.html or something like that (although I usually try to limit the hierarchy 
to 3-4 levels to make debugging easier).

Hope that helps.

R,
Dow



On May 18, 2013, at 2:14 AM, Parin Porecha  wrote:

> Hi,
> 
> I have just started to learn Django's template inheritance and I am stuck due 
> to this problem -
> In my application's 'base.html', I have defined two blocks -
> {% block topbar %}{% endblock topbar %}
> and
> {% block sidebar %}{% endblock sidebar %}
> 
> I have 2 templates - 'sidebar.html' which extends {% block sidebar %}
> and 'topbar.html' which extends {% block topbar %}
> 
> The 'sidebar.html' is also divided into further blocks which are extended by 
> other templates.
> 
> Now, my question is -
> in 'views.py', i have a view which is supposed to render the whole homepage ( 
> i.e.- including the sidebar, topbar and content ). So, which template should 
> I load in the view, so that both sidebar and topbar plus the content defined 
> in other templates gets shown ?
> because 'base.html' contains many children, I'm confused which one to load
> 
> Thanks to mattmc who tried to help me with this in IRC. Sorry, didn't get it 
> completely :)
> 
> -- 
> Regards,
> Parin Porecha
> 
> say Kifflom! and look forward to 17.09.13 !
> 
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can i access my database with Django?(Urgent)

[Dow Street]

Depending on what you're trying to do, I think you should be able to configure 
two separate databases in your settings file - one for the auth app (user 
tables, etc.) and one for your existing database.  Then use a database router 
to point each app to the right one.  This way the additional tables will not be 
added to your legacy database.

It seems easiest to use the 'default' database for auth and then route your 
models/app to the other database - e.g. 'legacy' or whatever.  It's been a 
while since I configured something like this so I might be missing something, 
but hopefully this helps...




DATABASES = {
   # legacy application
   'legacy': {
   'ENGINE': 'django.db.backends.postgresql_psycopg2', # db engine for 
postgres
   'NAME': 'legacy',   # database name in 
postgres
   'USER': 'postgres', # username to access 
postgres db
   'PASSWORD': '', # password to access 
postgres db
   'HOST': '10.10.10.10',  # address of 
linquest vm3
   'PORT': '5432', # default postgres 
port
   },

   # default database router maps objects from all other apps (e.g. auth, 
admin) to the
   # 'default' database
   'default': {
   'ENGINE': 'django.db.backends.postgresql_psycopg2', # db engine for 
postgres
   'NAME': 'users',# database name in 
postgres
   'USER': 'postgres', # username to access 
postgres db
   'PASSWORD': '', # password to access 
postgres db
   'HOST': '10.10.10.10',  # address of 
linquest vm3
   'PORT': '5432', # default postgres 
port
   }

}

DATABASE_ROUTERS = ['mysite.db_routers.LegacyRouter']






class LegacyRouter(object):
   """ Router that directs all database operations on models in the 'legacy'
   application to the 'legacy' database """

   def db_for_read(self, model, **hints):
   if model._meta.app_label == 'legacy':
   return 'legacy'
   return None 

   def db_for_write(self, model, **hints):
   if model._meta.app_label == 'legacy':
   return 'legacy'
   return None 

   def allow_relation(self, obj1, obj2, **hints):
   if obj1._meta.app_label == 'legacy' or obj2._meta.app_label == 'legacy':
   return True
   return None

   def allow_syncdb(self, db, model):
   if db == 'legacy':
   return model._meta.app_label == 'legacy'
   elif model._meta.app_label == 'legacy':
   return False
   return None 





On Apr 4, 2013, at 12:38 PM, Bill Freeman  wrote:

> I believe that additional tables are required to run Django, such as session 
> and user tables, stuff to do with permissions, stuff to do with content 
> types.  Maybe you can avoid these by not including the core applications in 
> INSTALLED_APPS, but then you couldn't log in to or be designated an superuser 
> to see the admin.  I don't know that code deeply enough to suggest a work 
> around.
> 
> 
> On Thu, Apr 4, 2013 at 2:22 PM, Giorgos Kontogiorgakis 
>  wrote:
> So,after i run the inspectdb i have a model.py file generated that creates 
> models by introspecting my existing database,right?After that thing i must 
> create an app and place the models.py that generated after running inspectdb 
> in there and then add the app to my INSTALLED_APPS setting and run the python 
> manage.py syncdb last?
> With this way will i be able to see the tables of my database on my webui and 
> NOT creating additional tables,right?Or i am wrong!?Please help me!
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

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