Please help me with django form 2.

[coded kid]

Hi guys, whenever I signup for my django form, my database is only
saving the id no and not names, username, email etc. |  #sorry for
posting it like this. I'm on mobile. Okay. In my views.py, this ( | )
means next line.@csrf_exempt
| def welcome(request): | if request.method=='POST': |
form=models.Register() |new_user=form.save() | return
HttpResponseRedirect('/logpage/') | else: |form=models.Register()|
return render_to_response('mainpage.html', {'form':models.Register}) .
I created an html form and a model with class Register(models.Model):

names=models.CharField(max_length=50) etc. I hope you get my point?
Please help.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Please help me with django form

[kenneth gonsalves]

On Tue, 2012-01-10 at 23:20 -0800, coded kid wrote:
> Hi guys, whenever I signup using the django form I created, my
> database is only saving the id no instead of username, email, first
> name etc. Please what should I do? 

please show us the relevant code
-- 
regards
Kenneth Gonsalves

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Please help me with django form

[coded kid]

Hi guys, whenever I signup using the django form I created, my
database is only saving the id no instead of username, email, first
name etc. Please what should I do?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[IgorS]

Thank you, Tom, for your thorough explanations (and moral support :-)
The situation is much clearer now. I hope this topic will be useful
for those who will later on join the wonderful Django world.

Thank you, Brian, for sharing your layout and experience. Actually, I
had been thinking about having multiple “small” directories (or sub-
apps) with small files – one models file, one tests file, etc., but
have never seen it implemented or discussed and was not sure if it was
possible and/or reasonable. I just wish your project was an open
source so I could learn more :-)

Thanks to everyone who participated in this discussion.


Best wishes,
-igor

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: scheduling in future

[Mike Dewhirst]

On 11/01/2012 4:09pm, Donald Casson wrote:

I would take a peek at celery and the eta function.  It allows you to
specify the task as specified in tasks.py with an eta to the
run_asynchronous method.  Hope this helps.


Looking it up as we speak

Thanks

Mike



Cheers
Don

On Jan 11, 2012 2:31 PM, "Mike Dewhirst" > wrote:

What is the best way to schedule future events in Django?

I have a table with future dates and user info. When date==today I
want Django to send an email to that user.

Ideas?

Thanks

Mike

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com
.
To unsubscribe from this group, send email to
django-users+unsubscribe@__googlegroups.com
.
For more options, visit this group at
http://groups.google.com/__group/django-users?hl=en
.

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: scheduling in future

[Donald Casson]

I would take a peek at celery and the eta function.  It allows you to
specify the task as specified in tasks.py with an eta to the
run_asynchronous method.  Hope this helps.

Cheers
Don
On Jan 11, 2012 2:31 PM, "Mike Dewhirst"  wrote:

> What is the best way to schedule future events in Django?
>
> I have a table with future dates and user info. When date==today I want
> Django to send an email to that user.
>
> Ideas?
>
> Thanks
>
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@**
> googlegroups.com .
> For more options, visit this group at http://groups.google.com/**
> group/django-users?hl=en
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: scheduling in future

[Wen 温业逵Yekui]

about sending email,you can utilize the libary function of django to do so

2012/1/11 Wen 温业逵Yekui 

> when you get the request of that user,you can get the "date" about the
> user from database ,then check if that date is today
>
>
> 2012/1/11 Mike Dewhirst 
>
>> What is the best way to schedule future events in Django?
>>
>> I have a table with future dates and user info. When date==today I want
>> Django to send an email to that user.
>>
>> Ideas?
>>
>> Thanks
>>
>> Mike
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to django-users+unsubscribe@**
>> googlegroups.com .
>> For more options, visit this group at http://groups.google.com/**
>> group/django-users?hl=en
>> .
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: scheduling in future

[Wen 温业逵Yekui]

when you get the request of that user,you can get the "date" about the user
from database ,then check if that date is today


2012/1/11 Mike Dewhirst 

> What is the best way to schedule future events in Django?
>
> I have a table with future dates and user info. When date==today I want
> Django to send an email to that user.
>
> Ideas?
>
> Thanks
>
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@**
> googlegroups.com .
> For more options, visit this group at http://groups.google.com/**
> group/django-users?hl=en
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

scheduling in future

[Mike Dewhirst]

What is the best way to schedule future events in Django?

I have a table with future dates and user info. When date==today I want 
Django to send an email to that user.


Ideas?

Thanks

Mike

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Changing the index page

[kalyan boga]

Hi,

I was working on tutorial 2 and i tried to change the layout of index page.
Copied the index.html template to my template folder under admin and
changed the contents to suit the site. The second line errors out :
{% load i18n admin_static %}

The error on the page reads :
TemplateSyntaxError at /admin/

'admin_static' is not a valid tag library: Template library
admin_static not found, tried
django.templatetags.admin_static,django.contrib.admin.templatetags.admin_static



What did i miss ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: /?next= not redirect user

[Guddu]

The way i did it was to have the following in my login template
(inside the login )



Replace /SiteRoot/url with whatever you would like the user to be
redirected to after a successful login.

Regards,
Guddu

On Jan 11, 7:39 am, Weldan  wrote:
> hi. can anyone show me how to do this . after successfully login user not
> redirected to request.path. thanks for advance

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: what is django.db.models.Q for?

[Wen 温业逵Yekui]

thanks!

2012/1/11 Eugene Wee 

> Hi,
>
> On Wed, Jan 11, 2012 at 10:27 AM, Yekui Wen  wrote:
> > can you guys tell me what is the Q method for ?
>
> Yes, though they are Q objects, not methods. Refer to:
>
> https://docs.djangoproject.com/en/1.3/topics/db/queries/#complex-lookups-with-q-objects
>
> Regards,
> Eugene
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

/?next= not redirect user

[Weldan]

hi. can anyone show me how to do this . after successfully login user not
redirected to request.path. thanks for advance

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: what is django.db.models.Q for?

[Eugene Wee]

Hi,

On Wed, Jan 11, 2012 at 10:27 AM, Yekui Wen  wrote:
> can you guys tell me what is the Q method for ?

Yes, though they are Q objects, not methods. Refer to:
https://docs.djangoproject.com/en/1.3/topics/db/queries/#complex-lookups-with-q-objects

Regards,
Eugene

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

what is django.db.models.Q for?

[Yekui Wen]

hey guys,  I need your help 
can you guys tell me what is the Q method for ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Two Column Aggregate

[Eugene Wee]

Hi,

I wrote some code to generate sales statistics. Unfortunately, for the
part where I compute total costs of all goods, I currently have a loop
which causes a query to be executed for each order item. This makes
the statistics generation very slow.

I have found that I can run a single query to obtain this total cost, e.g.,

SELECT SUM(pre.cost_price * oi.quantity)
FROM priceregistryelement AS pre
JOIN priceregistry AS pr ON pr.id=pre.price_registry_id
JOIN product AS p ON p.id=pr.product_id
JOIN orderitem AS oi ON oi.product_id=p.id;

This reduces the time taken from more than two minutes to less than a
second. Great, except that it is raw SQL, and I will need this to be
combined with filters and such.

I tried using extra() with aggregate() as described here:
http://stackoverflow.com/questions/2541864/sumproduct-using-djangos-aggregation
Unfortunately, I ran into a "FieldError: Cannot resolve keyword
'item_total' into field".

My idea is to have an aggregate to handle this, perhaps:

total_costs = Order.objects.aggregate(total_costs=SumProduct(
'items__product__price_registry__price_registry_elements__cost_price',
'items__quantity',
))['total_costs']

However, this proposed aggregate has two columns. Is it feasible to
implement this, and if so, how should I go about it?

Thank you,
Eugene Wee

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Using DISTINCT on related model fields

[John]

I found a solution from the annotate docs:

A.objects.values('b__name').distinct()

tada!  hope this helps someone else later :)

On Jan 10, 3:43 pm, John  wrote:
> I'm trying to express this query using the Django ORM:
>
> SELECT DISTINCT test_b.name FROM test_a LEFT JOIN test_b ON
> test_a.b_id = test_b.id
>
> using Django (with models 'A' and 'B') all I seem to be able to get is
>
> SELECT DISTINCT test_a.name, test_a.id FROM a INNER JOIN test_b ON
> test_a.b_id = test_b.id
>
> via the query:
>
> A.objects.all().distinct('b__name')
>
> I've tried various changes, including select_related() to try and
> convince it to follow the relation, but no matter what I do it ends up
> using the fields from the A model in the DISTINCT clause rather than
> B.  I assume that part of the problem is that the query I want to
> express does not return an A object, but I can't think of how to use
> the B model to phrase it in the ORM
> (B.objects.all.distinct('name').filter( "has at least one A
> model" ) ? )

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Matt Schinckel]

The way I generally do this type of thing 
is: https://gist.github.com/1591723

Lately, I've been using model validation: the clean() method instead of the 
save() method, but I can't remember if this is always called.

https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects

The other thing you can do is have a pre_save signal listener. That might 
be useful if you have several classes that need to have the same check done.

https://docs.djangoproject.com/en/dev/ref/signals/#pre-save

Regards,

Matt.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/CRw399vSaLIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django orm and no primary key

[Thorsten Sanders]

Am 10.01.2012 20:46, schrieb Ian Clelland:


This is possible -- there was some discussion on this list about it 
just a few days ago. If you tell Django that another field is the 
actual primary key, then it will not assume that there is an 'id' 
column (which is good, because otherwise it will try to include that 
in any SELECT statements that it issues).
Seems I should read more often the list, then I wouldnt have missed that 
one.




As long as you consider this table to be essentially read-only, and 
you don't try to use the ORM to create any records in it, then you 
shouldn't have any problems with this. As specific measures:


- Don't try to create records with Model.objects.create() or 
Model.objects.get_or_create()
- If you have to retrieve records, use filter() rather than get, if 
you can't ever assume uniqueness
- Similarly, if you have to update records, use update() rather than 
save().


It sounds like you want to use aggregate queries on this table anyway, 
so you (hopefully) shouldn't run into any issues.
Yep that fits from the orm side it is only reading to aggregate 
statistics from a table holding history data, I like the orm style way 
easier to write/manage than raw queries hence my question, the 
inserts/deletes are handled lowlevel without django.


And cheers for the answer gave me the motivation to try it out in the 
near future, currently I only still got that "primary key" to not break 
the orm, removing it would free up quite some not needed space if it works.


Oh, and don't register this model with the admin; most of that 
framework is built around the idea of rows uniquely addressable by 
their primary key.


--
Regards,
Ian Clelland
>
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.

To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: A demo of django-inlinetrans and django-inplaceedit

[rikuthero...@gmail.com]

Hi,

Thanks for publishing the project! It looks great :-)

El 10 de enero de 2012 09:56, J. Pablo Martín Cobos escribió:

> Hi,
>
> I hope that you like the demo:
>
> http://www.youtube.com/watch?v=_EjisXtMy_Y
>
> Set full sscreen mode to view it correctly
>
> Further information:
>
>
> http://www.yaco.es/blog/en/contribuciones/2012/01/inline-editing-and-translating-in-django/
>
> or Spanish version:
>
>
> http://www.yaco.es/blog/contribuciones/2012/01/inline-editing-and-translating-in-django/
>
> Regards,
>
> --
>
> Pablo Martín
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>



-- 
Pablo Recio Quijano

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: how to only allow google apps auth from one domain

[Tony Schmidt]

Got it: Hacked the django-social-auth Google back-end to filter by
domain.  I'll see if the project wants to accept my changes as a
setting.

On Jan 9, 5:38 pm, Tony Schmidt  wrote:
> I tried django-social-authand googleappsauth but both allow me to
> authenticate from anydomain.  Has anybody had luck setting this up
> with these, or any other packages?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[jrief]

OK, now I got it.
Coming from C++ I was stuck too much in static inheritance thinking. The 
diagram in http://fuhm.net/super-harmful/ helped me to understand this 
issue.
Thank you very much for your help!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/5YNg501CZwcJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Using DISTINCT on related model fields

[John]

I'm trying to express this query using the Django ORM:

SELECT DISTINCT test_b.name FROM test_a LEFT JOIN test_b ON
test_a.b_id = test_b.id

using Django (with models 'A' and 'B') all I seem to be able to get is

SELECT DISTINCT test_a.name, test_a.id FROM a INNER JOIN test_b ON
test_a.b_id = test_b.id

via the query:

A.objects.all().distinct('b__name')

I've tried various changes, including select_related() to try and
convince it to follow the relation, but no matter what I do it ends up
using the fields from the A model in the DISTINCT clause rather than
B.  I assume that part of the problem is that the query I want to
express does not return an A object, but I can't think of how to use
the B model to phrase it in the ORM
(B.objects.all.distinct('name').filter( "has at least one A
model" ) ? )

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Jeff]

Sigh.  I hate Google Groups via web.  Here is a readable version of
the .save() method below.

https://gist.github.com/1591028

On Jan 10, 3:15 pm, Jeff  wrote:
> For example, altering 'pana.our.org''s netgroups field, the following
> save() method results in this debug line which makes no sense to me:
>
>     CHANGED: Device pana.our.org had old netgroups [{'name':
> u'testnetgroup', 'desc': u''}] and now has new netgroups [{'name':
> u'testnetgroup', 'desc': u''}]
>
> Both the new and old netgroups in that line are identical and reflect
> the NEW value.  Working code would state:
>
>     CHANGED: Device pana.our.org had old netgroups [{'name':
> u'testnetgroup', 'desc': u''}] and now has new netgroups []
>
> class Device(models.Model):
>     # ...
>     netgroups       = models.ManyToManyField(Netgroup,
>                                              null=True,
>                                              verbose_name="Netgroups",
>                                              blank=True)
>     # ...
>     def save(self, *args, **kwargs):
>         try:
>             #
>             # Get the THEORETICALLY old data from database for this
> device
>             #
>             oldnetgroups =
> Device.objects.get(pk=self.pk).netgroups.values_list()
>         except:
>             # This is likely a brand new device object, so can't look
> it up
>             oldnetgroups = None
>         #
>         # Compare the THEORETICAL old netgroups value with the
> theoretical new value
>         #
>         if (oldnetgroups != None) and (oldnetgroups !=
> self.netgroups.values_list()):
>             prefix = 'CHANGED'
>         else:
>             prefix = 'UNCHANGED'
>         if oldnetgroups != None:
>             fd = open('/tmp/test.log', 'a')
>             fd.write('%s: Device %s had old netgroups %s and now has
> new netgroups %s\n' % (prefix, self.name, oldnetgroups,
> self.netgroups.values()))
>             fd.close()
>         super(Device, self).save(*args, **kwargs)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Cal Leeming [Simplicity Media Ltd]]

That's a good point - although I can't think how to explain it in words..
Makes me wonder if I should do a blog post about this infact... *adds into
todo list, amongst the other 9000 tasks he has* lol.

On Tue, Jan 10, 2012 at 6:54 PM, Derek  wrote:

> Cal
>
> I agree that its true that having more experience allows you to build
> better web apps and get smarter about how you do that. But I disagree
> that someone with that experience cannot share some or part of the
> "why and how" that is done.  And I hope someone will be able to :)
>
> Derek
>
> On 10 January 2012 13:01, Cal Leeming [Simplicity Media Ltd]
>  wrote:
> > I've hit this same problem myself many times.
> >
> > Ultimately there is never any one answer - you can split out
> functionality
> > into individual modules, but there has to be a good use case for it,
> > otherwise the overhead has a negative impact.
> >
> > You also have to take into consideration the re-usability of what you are
> > splitting out, and if something is split out, then it has to be treated
> as a
> > standardized module which is kept backwards compatible for everything.
> >
> > It's not just a case of having a standardized directory layout, the
> entire
> > use case of the project will determine the layout - you can follow 'sane
> > principles' such as naming convention etc, but the actual splitting of
> > functionality is really up to the developer (and isn't really something
> that
> > can be taught - it's more of an experience thing).
> >
> > Personally, I found that using 'MultiHostMiddleware' has been an absolute
> > life saver for splitting out sites within a single project - check it
> > out: http://code.djangoproject.com/wiki/MultiHostMiddleware (I just
> went and
> > tidied it up a bit).
> >
> > Just my two cents worth!
> >
> > Cal
> >
> > On Tue, Jan 10, 2012 at 6:46 AM, Derek  wrote:
> >>
> >> Brian
> >>
> >> That is useful "generic" advice and a topic I am very interested in -
> >> how to break up an "enterprise" type of application into smaller apps
> >> (to enable distribution of sub-sections to different types of
> >> audiences) while at the same time maintaining tight coherency among
> >> closely-related data sets.  In this case there is a typically a "core"
> >> data set and then many other more peripheral ones that all need to
> >> connect to the core.  I have not yet seen any example of such a design
> >> process - or even a set of principles - which describe *how* to
> >> achieve such a design.
> >>
> >> Derek
> >>
> >> On 9 January 2012 18:18, Brian Schott  wrote:
> >> > My advice is If you find yourself breaking models, views, utils, etc.
> >> > into separate files within an app, you should really consider
> breaking your
> >> > app into multiple apps.  I hit this myself in or own project and found
> >> > myself dealing with the auto registration functionality for admin.py,
> >> > tasks.py, and a bunch of other too-large files.  I bit the bullet and
> broke
> >> > things out and my import/discovery headaches disappeared.  My
> individual py
> >> > files got small and
> >> >
> >> > +--major_app
> >> > +--docs
> >> > +--templates
> >> >  +-- (img, js, css, base.html)
> >> > +--projects
> >> >  +--dev
> >> >  +--test
> >> >  +--deploy
> >> > +--apps
> >> >  +--sub_app1(create with startapp command)
> >> >   +--models.py
> >> >   +--tasks.py
> >> >   +--templates
> >> >   +--tests.py
> >> >   +--urls.py
> >> >   +--views.py
> >> >   +--...
> >> >  +--sub_app2
> >> >   +-- .
> >> >
> >> > I put this in the top of my settings.py files down in projects/dev or
> >> > projects/test, or projects/deploy so that the apps just get
> discovered.
> >> >
> >> > # the base directory is up two levels from the project
> >> > PROJDIR = os.path.abspath(os.path.dirname(__file__)) + '/'
> >> > PROJNAME = PROJDIR.split('/')[-2]
> >> > BASEDIR = os.path.abspath(os.path.join(PROJDIR, '..', '..')) + '/'
> >> > APPSDIR = os.path.abspath(os.path.join(BASEDIR, 'apps')) + '/'
> >> >
> >> > # add apps and projects directory to path
> >> > sys.path.insert(0, PROJDIR)
> >> > sys.path.insert(0, APPSDIR)
> >> >
> >> > Brian
> >> >
> >> > Brian Schott
> >> > bfsch...@gmail.com
> >> >
> >> > On Jan 7, 2012, at 2:24 PM, IgorS wrote:
> >> >
> >> >> Below is my current structure. I am new to Django and probably
> missing
> >> >> something... Restructuring an application somewhere in the middle of
> >> >> the development cycle is more expensive than just having the "right"
> >> >> layout from the start. Especially if this is possible. I consider a
> >> >> small overhead at the start being better than a great rework in the
> >> >> middle (yes, i am aware of the minimal viable product concept :-)
> >> >>
> >> >> app
> >> >> 

Re: Need to examine and act on old vs. new at .save() time

[Jeff]

For example, altering 'pana.our.org''s netgroups field, the following
save() method results in this debug line which makes no sense to me:

CHANGED: Device pana.our.org had old netgroups [{'name':
u'testnetgroup', 'desc': u''}] and now has new netgroups [{'name':
u'testnetgroup', 'desc': u''}]

Both the new and old netgroups in that line are identical and reflect
the NEW value.  Working code would state:

CHANGED: Device pana.our.org had old netgroups [{'name':
u'testnetgroup', 'desc': u''}] and now has new netgroups []

class Device(models.Model):
# ...
netgroups   = models.ManyToManyField(Netgroup,
 null=True,
 verbose_name="Netgroups",
 blank=True)
# ...
def save(self, *args, **kwargs):
try:
#
# Get the THEORETICALLY old data from database for this
device
#
oldnetgroups =
Device.objects.get(pk=self.pk).netgroups.values_list()
except:
# This is likely a brand new device object, so can't look
it up
oldnetgroups = None
#
# Compare the THEORETICAL old netgroups value with the
theoretical new value
#
if (oldnetgroups != None) and (oldnetgroups !=
self.netgroups.values_list()):
prefix = 'CHANGED'
else:
prefix = 'UNCHANGED'
if oldnetgroups != None:
fd = open('/tmp/test.log', 'a')
fd.write('%s: Device %s had old netgroups %s and now has
new netgroups %s\n' % (prefix, self.name, oldnetgroups,
self.netgroups.values()))
fd.close()
super(Device, self).save(*args, **kwargs)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django orm and no primary key

[Ian Clelland]

On Tue, Jan 10, 2012 at 9:04 AM, webonomic  wrote:

> The Django Book alludes to this, and maybe the comments there will
> help you.
>
> Go to http://www.djangobook.com/en/1.0/chapter05/
> and search for this paragraph:
>
> "Finally, note we haven’t explicitly defined a primary key in any of
> these models. Unless you instruct it otherwise, Django automatically
> gives every model an auto-incrementing integer primary key field
> called id. Each Django model is required to have a single-column
> primary key."
>

This is referring to an implicit primary key, which Django will create if
you do not specify one. The question was regarding using an existing table
with no PK in Django.

> I am wondering if it is possible to still use the django orm without
> > having a primary key at all, I currently got a table holding 61 million
> > entries soon gonna expand to hold 600 million entries, that table never
> > need to identify one entry alone its only to pull off statistics based
> > on other fields, so far I  dropped the primary key index in the database
> > and all works fine, but I know the orm always want a primary key, would
> > it still work if I for example claim one of the fields which aren't
> > unique as the primary key?
> >
> > Or is the only way to do it, use the cursor or even mysqldb directly?
>

This is possible -- there was some discussion on this list about it just a
few days ago. If you tell Django that another field is the actual primary
key, then it will not assume that there is an 'id' column (which is good,
because otherwise it will try to include that in any SELECT statements that
it issues).

As long as you consider this table to be essentially read-only, and you
don't try to use the ORM to create any records in it, then you shouldn't
have any problems with this. As specific measures:

- Don't try to create records with Model.objects.create() or
Model.objects.get_or_create()
- If you have to retrieve records, use filter() rather than get, if you
can't ever assume uniqueness
- Similarly, if you have to update records, use update() rather than save().

It sounds like you want to use aggregate queries on this table anyway, so
you (hopefully) shouldn't run into any issues.

Oh, and don't register this model with the admin; most of that framework is
built around the idea of rows uniquely addressable by their primary key.

-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Tom Evans]

On Tue, Jan 10, 2012 at 6:13 PM, IgorS  wrote:
> First of all, thanks a lot to everyone who replied :-)
>
> Tom:
>
> As i mentioned, i am new to Django and could be missing big parts.
> Please do not hate me too much for my naivete :-)

Never apologise for trying to learn :) It took me a really long time
to get to grips with how apps should interact with projects. You've
avoided many of the problems I encounter with my production sites :)

> But I have some doubts regarding the templates. And the doubts come
> exactly from that [explicit vs. implicit] perspective. Why not making
> it more explicit? I mean to change it in a way that there is no need
> to relay on the order in which Django searches for the templates. The
> order is defined at the project level and this unnecessarily couples
> my application with the project.

Python programming tends to have at least two golden rules*:

1) Explicit is better than implicit
2) Don't repeat yourself

Sometimes I feel that that these two rules are at odds with each
other, and this would be one of those cases. It would be more explicit
to manually resolve the template that you want in the view, but then
we would have to manually resolve which template in every view :)

So instead, the best way is to explicitly include the app name in the
template name, by keeping templates in a subdirectory named after the
app, and allow simple template loaders to find it. This actually
reduces coupling, as another poster has alluded to, as you can
override a specific app's template on the project level. As an
example, when using django's admin app, you can override specific
templates by creating the appropriately named template in your project
template directory:

https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#overriding-admin-templates

If the view manually resolved the template to use, you would need to
provide a mechanism to allow a project to override an app template.
Remember that the app author is not necessarily the project author.

> The only two places where the templates are referenced are the views
> and other templates (in the “extends” tag). Please correct me if I am
> wrong.

Well, technically templates can be used for generating any textual
content, for instance I use templates to generate email contents in
backend (non website driven) processes. But yes, pretty much - and the
use is pretty much the same (render_to_string() rather than
render_to_response() or render()).

[...]

> Am I digging in a wrong direction? Is it easier to just rely on the
> Django's template scanning order and to forget the whole thing?
> What do you think?

Yep, I think that the current 'standard' of prefixing your templates
with your app name is pretty good. There are no major flaws in how it
currently operates, and it offers a lot of flexibility.

Cheers

Tom

* I always add this rule to any golden rules:
3) You don't always have to obey golden rules!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Donald Stufft]

On Tuesday, January 10, 2012 at 1:13 PM, IgorS wrote:
> First of all, thanks a lot to everyone who replied :-)
>  
> Tom:
>  
> As i mentioned, i am new to Django and could be missing big parts.
> Please do not hate me too much for my naivete :-)
>  
> The approach you suggested regarding the static files seems to be
> reasonable. Especially considering that the static files will
> eventually go to a separate server.
>  
> But I have some doubts regarding the templates. And the doubts come
> exactly from that [explicit vs. implicit] perspective. Why not making
> it more explicit? I mean to change it in a way that there is no need
> to relay on the order in which Django searches for the templates. The
> order is defined at the project level and this unnecessarily couples
> my application with the project.
>  
>  

A big reason to keep it the current way, is that typically the project level 
templates will override app level templates. This let's you create reusable 
apps and distribute them with default templates, but allow other apps or the 
project itself to override those templates without having to modify the 
original app.  
>  
> The only two places where the templates are referenced are the views
> and other templates (in the “extends” tag). Please correct me if I am
> wrong. Making it more explicit in the views is simple. E.g., it can be
> done like this:
> template = app_settings.path_to_template('base.html')
> return render_to_response(template, …)
> Here app_settings.py is a settings file that stays in the
> application's root folder; and path_to_template is an application-
> specific function, which returns absolute path to the template (using
> os.path and the name of the app's folder).
>  
> Dealing with the templates that reference other templates (in the
> “extends” tag) seems a bit trickier... One way that I found is to use
> a variable in the “extends” tag. But that will require some code in
> the application-specific context processor, which in turn will need to
> be specified at the project level in settings.py in
> TEMPLATE_CONTEXT_PROCESSORS.
> In that case I can do something like this in the templates:
> {% extends _TEMPLATES.base %}
> where base is a key in the _TEMPLATES dictionary whose value
> contains absolute path to the base.html.
>  
> This approach seems to be more explicit but also a bit more
> complicated and still depends on the settings at the project level (on
> the other hand, having an application-level context processor seems to
> be almost inevitable). And yes, my solution seems to be somehow half-
> baked…
>  
> Can this problem with the “extends” tag be solved in a more elegant
> way?
> Am I digging in a wrong direction? Is it easier to just rely on the
> Django's template scanning order and to forget the whole thing?
> What do you think?
>  
> Thank you,
> -igor
>  
> >  
> > Looks pretty good, the only thing I would change would be to prefix
> > templates and static files with the app name, by placing them inside a
> > directory named after the app, eg 'app/templates/app/index.html', as
> > this will avoid conflicts with other templates/static media.
> >  
> > Cheers
> >  
> > Tom
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com 
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>  
>  


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Derek]

Cal

I agree that its true that having more experience allows you to build
better web apps and get smarter about how you do that. But I disagree
that someone with that experience cannot share some or part of the
"why and how" that is done.  And I hope someone will be able to :)

Derek

On 10 January 2012 13:01, Cal Leeming [Simplicity Media Ltd]
 wrote:
> I've hit this same problem myself many times.
>
> Ultimately there is never any one answer - you can split out functionality
> into individual modules, but there has to be a good use case for it,
> otherwise the overhead has a negative impact.
>
> You also have to take into consideration the re-usability of what you are
> splitting out, and if something is split out, then it has to be treated as a
> standardized module which is kept backwards compatible for everything.
>
> It's not just a case of having a standardized directory layout, the entire
> use case of the project will determine the layout - you can follow 'sane
> principles' such as naming convention etc, but the actual splitting of
> functionality is really up to the developer (and isn't really something that
> can be taught - it's more of an experience thing).
>
> Personally, I found that using 'MultiHostMiddleware' has been an absolute
> life saver for splitting out sites within a single project - check it
> out: http://code.djangoproject.com/wiki/MultiHostMiddleware (I just went and
> tidied it up a bit).
>
> Just my two cents worth!
>
> Cal
>
> On Tue, Jan 10, 2012 at 6:46 AM, Derek  wrote:
>>
>> Brian
>>
>> That is useful "generic" advice and a topic I am very interested in -
>> how to break up an "enterprise" type of application into smaller apps
>> (to enable distribution of sub-sections to different types of
>> audiences) while at the same time maintaining tight coherency among
>> closely-related data sets.  In this case there is a typically a "core"
>> data set and then many other more peripheral ones that all need to
>> connect to the core.  I have not yet seen any example of such a design
>> process - or even a set of principles - which describe *how* to
>> achieve such a design.
>>
>> Derek
>>
>> On 9 January 2012 18:18, Brian Schott  wrote:
>> > My advice is If you find yourself breaking models, views, utils, etc.
>> > into separate files within an app, you should really consider breaking your
>> > app into multiple apps.  I hit this myself in or own project and found
>> > myself dealing with the auto registration functionality for admin.py,
>> > tasks.py, and a bunch of other too-large files.  I bit the bullet and broke
>> > things out and my import/discovery headaches disappeared.  My individual py
>> > files got small and
>> >
>> > +--major_app
>> >     +--docs
>> >     +--templates
>> >          +-- (img, js, css, base.html)
>> >     +--projects
>> >          +--dev
>> >          +--test
>> >          +--deploy
>> >     +--apps
>> >          +--sub_app1    (create with startapp command)
>> >               +--models.py
>> >               +--tasks.py
>> >               +--templates
>> >               +--tests.py
>> >               +--urls.py
>> >               +--views.py
>> >               +--...
>> >          +--sub_app2
>> >               +-- .
>> >
>> > I put this in the top of my settings.py files down in projects/dev or
>> > projects/test, or projects/deploy so that the apps just get discovered.
>> >
>> > # the base directory is up two levels from the project
>> > PROJDIR = os.path.abspath(os.path.dirname(__file__)) + '/'
>> > PROJNAME = PROJDIR.split('/')[-2]
>> > BASEDIR = os.path.abspath(os.path.join(PROJDIR, '..', '..')) + '/'
>> > APPSDIR = os.path.abspath(os.path.join(BASEDIR, 'apps')) + '/'
>> >
>> > # add apps and projects directory to path
>> > sys.path.insert(0, PROJDIR)
>> > sys.path.insert(0, APPSDIR)
>> >
>> > Brian
>> >
>> > Brian Schott
>> > bfsch...@gmail.com
>> >
>> > On Jan 7, 2012, at 2:24 PM, IgorS wrote:
>> >
>> >> Below is my current structure. I am new to Django and probably missing
>> >> something... Restructuring an application somewhere in the middle of
>> >> the development cycle is more expensive than just having the "right"
>> >> layout from the start. Especially if this is possible. I consider a
>> >> small overhead at the start being better than a great rework in the
>> >> middle (yes, i am aware of the minimal viable product concept :-)
>> >>
>> >> app
>> >>       +--models
>> >>               ---abstract_base.py
>> >>               ---core.py
>> >>               ---...
>> >>       +--probe
>> >>       +--static
>> >>               ---css
>> >>               ---js
>> >>               ---images
>> >>       +--templates
>> >>               ---base.html
>> >>               ---...
>> >>       +--tests
>> >>               ---test_users.py
>> >>               ---...
>> >>       +--utils
>> >>       +--views
>> >>       ---__init__.py
>> >>       ---app_settings.py
>> 

Re: Directory layout for a large Django application (not project)

[IgorS]

First of all, thanks a lot to everyone who replied :-)

Tom:

As i mentioned, i am new to Django and could be missing big parts.
Please do not hate me too much for my naivete :-)

The approach you suggested regarding the static files seems to be
reasonable. Especially considering that the static files will
eventually go to a separate server.

But I have some doubts regarding the templates. And the doubts come
exactly from that [explicit vs. implicit] perspective. Why not making
it more explicit? I mean to change it in a way that there is no need
to relay on the order in which Django searches for the templates. The
order is defined at the project level and this unnecessarily couples
my application with the project.

The only two places where the templates are referenced are the views
and other templates (in the “extends” tag). Please correct me if I am
wrong. Making it more explicit in the views is simple. E.g., it can be
done like this:
template = app_settings.path_to_template('base.html')
return render_to_response(template, …)
Here app_settings.py is a settings file that stays in the
application's root folder; and path_to_template is an application-
specific function, which returns absolute path to the template (using
os.path and the name of the app's folder).

Dealing with the templates that reference other templates (in the
“extends” tag) seems a bit trickier... One way that I found is to use
a variable in the “extends” tag. But that will require some code in
the application-specific context processor, which in turn will need to
be specified at the project level in settings.py in
TEMPLATE_CONTEXT_PROCESSORS.
In that case I can do something like this in the templates:
{% extends _TEMPLATES.base %}
where base is a key in the _TEMPLATES dictionary whose value
contains absolute path to the base.html.

This approach seems to be more explicit but also a bit more
complicated and still depends on the settings at the project level (on
the other hand, having an application-level context processor seems to
be almost inevitable).  And yes, my solution seems to be somehow half-
baked…

Can this problem with the “extends” tag be solved in a more elegant
way?
Am I digging in a wrong direction? Is it easier to just rely on the
Django's template scanning order and to forget the whole thing?
What do you think?

Thank you,
-igor

>
> Looks pretty good, the only thing I would change would be to prefix
> templates and static files with the app name, by placing them inside a
> directory named after the app, eg 'app/templates/app/index.html', as
> this will avoid conflicts with other templates/static media.
>
> Cheers
>
> Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django orm and no primary key

[webonomic]

The Django Book alludes to this, and maybe the comments there will
help you.

Go to http://www.djangobook.com/en/1.0/chapter05/
and search for this paragraph:

"Finally, note we haven’t explicitly defined a primary key in any of
these models. Unless you instruct it otherwise, Django automatically
gives every model an auto-incrementing integer primary key field
called id. Each Django model is required to have a single-column
primary key."

Jared

On Jan 9, 3:45 pm, Thorsten Sanders  wrote:
> Hello,
>
> I am wondering if it is possible to still use the django orm without
> having a primary key at all, I currently got a table holding 61 million
> entries soon gonna expand to hold 600 million entries, that table never
> need to identify one entry alone its only to pull off statistics based
> on other fields, so far I  dropped the primary key index in the database
> and all works fine, but I know the orm always want a primary key, would
> it still work if I for example claim one of the fields which aren't
> unique as the primary key?
>
> Or is the only way to do it, use the cursor or even mysqldb directly?
>
> Greetings,
> Thorsten

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Jeff]

On Jan 10, 10:42 am, Kelly Nicholes  wrote:
> Isn't there a form.changed_data ?

See 1st post below indicating we manipulate Django data from various
Django
codebases, not just a web form.

> > I need to.. ... How 
> > can I do this,
> > bearing in mind that we call .save() from non-web code, etc?  We use
> > Django's ORM from various other non-web interfaces and code.  My point
> > is that we can't just inspect a web form's result data.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Jeff]

On Jan 10, 10:09 am, Nahuel Defossé  wrote:
> I think you should see at the forms's cleaned_data attribute and
> compare it against the model current state, before saving.

As I indicated in the 1st post:

> >> > I need to ...   ...  
> >> > How can I do this,
> >> > bearing in mind that we call .save() from non-web code, etc?  We use
> >> > Django's ORM from various other non-web interfaces and code.  My point
> >> > is that we can't just inspect a web form's result data.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Brian Schott]

Interesting!   So, that means you can serve blog.example.com and 
shop.example.com from the same server?  I haven't tried any of the multi-site 
support in django, so not sure how this compares.  Makes my head hurt to think 
what this does to SSL.   I've never been able to figure out SSL and virtual 
hosting on Apache.

Brian Schott
bfsch...@gmail.com



On Jan 10, 2012, at 6:01 AM, Cal Leeming [Simplicity Media Ltd] wrote:

> I've hit this same problem myself many times.
> 
> Ultimately there is never any one answer - you can split out functionality 
> into individual modules, but there has to be a good use case for it, 
> otherwise the overhead has a negative impact.
> 
> You also have to take into consideration the re-usability of what you are 
> splitting out, and if something is split out, then it has to be treated as a 
> standardized module which is kept backwards compatible for everything.
> 
> It's not just a case of having a standardized directory layout, the entire 
> use case of the project will determine the layout - you can follow 'sane 
> principles' such as naming convention etc, but the actual splitting of 
> functionality is really up to the developer (and isn't really something that 
> can be taught - it's more of an experience thing).
> 
> Personally, I found that using 'MultiHostMiddleware' has been an absolute 
> life saver for splitting out sites within a single project - check it out: 
> http://code.djangoproject.com/wiki/MultiHostMiddleware (I just went and 
> tidied it up a bit).
> 
> Just my two cents worth!
> 
> Cal
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.



smime.p7s
Description: S/MIME cryptographic signature

Re: Directory layout for a large Django application (not project)

[Brian Schott]

I see I broke off mid thought, my individual py files got small and I didn't 
have to do any of my own sub-file discovery logic to do something like 
"models/foo_models.py", "models/bar_models.py"...  There is nothing preventing 
tight foreign-key relationships across apps.  In reality, all of the tables are 
in the same database.  

I also use:

class Meta:
app_label = 'major_app'

in the model class of each sub_app, so that all of the admin pages are grouped 
together.  

Brian

Brian Schott
bfsch...@gmail.com



On Jan 10, 2012, at 1:46 AM, Derek wrote:

> Brian
> 
> That is useful "generic" advice and a topic I am very interested in -
> how to break up an "enterprise" type of application into smaller apps
> (to enable distribution of sub-sections to different types of
> audiences) while at the same time maintaining tight coherency among
> closely-related data sets.  In this case there is a typically a "core"
> data set and then many other more peripheral ones that all need to
> connect to the core.  I have not yet seen any example of such a design
> process - or even a set of principles - which describe *how* to
> achieve such a design.
> 
> Derek
> 
> On 9 January 2012 18:18, Brian Schott  wrote:
>> My advice is If you find yourself breaking models, views, utils, etc. into 
>> separate files within an app, you should really consider breaking your app 
>> into multiple apps.  I hit this myself in or own project and found myself 
>> dealing with the auto registration functionality for admin.py, tasks.py, and 
>> a bunch of other too-large files.  I bit the bullet and broke things out and 
>> my import/discovery headaches disappeared.  My individual py files got small 
>> and
>> 
>> +--major_app
>> +--docs
>> +--templates
>>  +-- (img, js, css, base.html)
>> +--projects
>>  +--dev
>>  +--test
>>  +--deploy
>> +--apps
>>  +--sub_app1(create with startapp command)
>>   +--models.py
>>   +--tasks.py
>>   +--templates
>>   +--tests.py
>>   +--urls.py
>>   +--views.py
>>   +--...
>>  +--sub_app2
>>   +-- .
>> 
>> I put this in the top of my settings.py files down in projects/dev or 
>> projects/test, or projects/deploy so that the apps just get discovered.
>> 
>> # the base directory is up two levels from the project
>> PROJDIR = os.path.abspath(os.path.dirname(__file__)) + '/'
>> PROJNAME = PROJDIR.split('/')[-2]
>> BASEDIR = os.path.abspath(os.path.join(PROJDIR, '..', '..')) + '/'
>> APPSDIR = os.path.abspath(os.path.join(BASEDIR, 'apps')) + '/'
>> 
>> # add apps and projects directory to path
>> sys.path.insert(0, PROJDIR)
>> sys.path.insert(0, APPSDIR)
>> 
>> Brian
>> 
>> Brian Schott
>> bfsch...@gmail.com
>> 
>> On Jan 7, 2012, at 2:24 PM, IgorS wrote:
>> 
>>> Below is my current structure. I am new to Django and probably missing
>>> something... Restructuring an application somewhere in the middle of
>>> the development cycle is more expensive than just having the "right"
>>> layout from the start. Especially if this is possible. I consider a
>>> small overhead at the start being better than a great rework in the
>>> middle (yes, i am aware of the minimal viable product concept :-)
>>> 
>>> app
>>>   +--models
>>>   ---abstract_base.py
>>>   ---core.py
>>>   ---...
>>>   +--probe
>>>   +--static
>>>   ---css
>>>   ---js
>>>   ---images
>>>   +--templates
>>>   ---base.html
>>>   ---...
>>>   +--tests
>>>   ---test_users.py
>>>   ---...
>>>   +--utils
>>>   +--views
>>>   ---__init__.py
>>>   ---app_settings.py
>>>   ---context_processors.py
>>>   ---middleware.py
>>>   ---urls.py
>>> 
>>> Thank you,
>>> -igor
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Need to examine and act on old vs. new at .save() time

[Kelly Nicholes]

Isn't there a form.changed_data ?

On Jan 9, 6:39 pm, Jeff  wrote:
> Hi all,
>
> I need to be able to determine, at .save() time (before I call the
> parent class' .save()), if a certain field on my model object was
> changed, and act on that via some custom code.  How can I do this,
> bearing in mind that we call .save() from non-web code, etc?  We use
> Django's ORM from various other non-web interfaces and code.  My point
> is that we can't just inspect a web form's result data.
>
> I'd appreciate any thoughts.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Nahuel Defossé]

Hi,
I think you should see at the forms's cleaned_data attribute and
compare it against the model current state, before saving.

Regards
Nahuel

2012/1/10 Jeff :
> On Jan 10, 8:14 am, Andre Terra  wrote:
>> You can override the model's save method?[1][2]
>
> Hi Andre,
>
> Thanks for replying.  Yes, I'm aware that I need to override .save().
> See:
>
>> > I need to be able to determine, at .save() time (before I call the
>> > parent class' .save()), ...
>
> I need to know how to, in my custom .save() for a model:
>
> a) determine what fields changed (if any) (HOW?)
> b) and take certain actions if field X was one of the changed fields.
> (I know how)
>
>> On Mon, Jan 9, 2012 at 11:39 PM, Jeff  wrote:
>> > Hi all,
>>
>> > I need to be able to determine, at .save() time (before I call the
>> > parent class' .save()), if a certain field on my model object was
>> > changed, and act on that via some custom code.  How can I do this,
>> > bearing in mind that we call .save() from non-web code, etc?  We use
>> > Django's ORM from various other non-web interfaces and code.  My point
>> > is that we can't just inspect a web form's result data.
>>
>> > I'd appreciate any thoughts.
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Django users" group.
>> > To post to this group, send email to django-users@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> >http://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Jeff]

On Jan 10, 8:14 am, Andre Terra  wrote:
> You can override the model's save method?[1][2]

Hi Andre,

Thanks for replying.  Yes, I'm aware that I need to override .save().
See:

> > I need to be able to determine, at .save() time (before I call the
> > parent class' .save()), ...

I need to know how to, in my custom .save() for a model:

a) determine what fields changed (if any) (HOW?)
b) and take certain actions if field X was one of the changed fields.
(I know how)

> On Mon, Jan 9, 2012 at 11:39 PM, Jeff  wrote:
> > Hi all,
>
> > I need to be able to determine, at .save() time (before I call the
> > parent class' .save()), if a certain field on my model object was
> > changed, and act on that via some custom code.  How can I do this,
> > bearing in mind that we call .save() from non-web code, etc?  We use
> > Django's ORM from various other non-web interfaces and code.  My point
> > is that we can't just inspect a web form's result data.
>
> > I'd appreciate any thoughts.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Dual license in a django world

[Derek]

I think you can already derive commercial apps if you so desire,
without any license restrictions.  See this post:
http://jacobian.org/writing/paid-django-apps/ - a number of the
comments point to existing commercial apps.


On Jan 9, 8:46 pm, Thomas Weholt  wrote:
> It´s been harder and harder to justify the time spent on my spare time
> projects, none of which generate any income. I´m currently working on
> a project I believe may have some commercial possebilities and was
> wondering if I could try a dual license to generate income. For
> personal or non-commercial use there be a BSD or GPL license and some
> other license for commercial use ( what license to use ? what to
> charge? ). I´m not talking about huge license fees ( $99 for a single
> site ?? ) and have no dream about quitting my day-time job any time
> soon, but it would be much easier to justify spending time on my
> django projects if they generated some kind of income.
>
> What do you think? How would a dual license be recieved in the django
> community? Any tip or thought on the subject would be appreciated.
>
> --
> Mvh/Best regards,
> Thomas Weholthttp://www.weholt.org

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[Tom Evans]

On Tue, Jan 10, 2012 at 2:05 PM, jrief  wrote:
> But the mixin plugins are not derived from django.views.generic.DetailView,
> otherwise the main app's DetailView would obtain a diamond shaped
> inheritance.

Well, that is evident isn't it - they are mixins. If they were derived
from DetailView, they would be subclasses.

Besides which, with python multiple inheritance, you don't get a
diamond, you get a chain, see below.

>
> And django.views.generic.detail.BaseDetailView.get calls get_context_data
> only once, so I don't see how the plugins shall "deliver" their contexts.

Welcome to the world of the MRO - Method Resolution Order. This SO
post gives a good example of how MRO works:

http://stackoverflow.com/questions/2010692/what-does-mro-do-in-python

This page*, particularly the diagram in the "Argument passing, argh!"
section should make it clearer how a diamond inheritance is handled
(viz. it's not a diamond):

http://fuhm.net/super-harmful/

Got that? OK, so when you have a class like this:

class MyView(Mixin1, Mixin2, SomeSuperView):

then the MRO for this class will look something like this:

(MyView, Mixin1, Mixin2, SomeSuperView, object)

When you call MyView.get_context_data and call super(MyView,
self).get_context_data, it will first try Mixin1.get_context_data,
which if exists should call super(Mixin1, self).get_context_data, and
so on up the MRO stack.


Cheers

Tom

* super is not harmful, no matter what that page says. It is just that
you must be consistent when using it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[Andre Terra]

Python will use solve the diamond problem through MRO[1], so it all depends
on the order you in which you mix your classes.


class MyBaseView(BaseDetailView):
def get_context_data(self, *args, **kwargs):
context = super(MyBaseView, self).get_context_data(*args, **kwargs)
context['foo'] = 'MyView'

return context

class MixinA(object):
def get_context_data(self, *args, **kwargs):
context = super(MixinA, self).get_context_data(*args, **kwargs)
context['foo'] = 'MixinA'

return context

class MixinB(object):
def get_context_data(self, *args, **kwargs):
context = super(MixinB, self).get_context_data(*args, **kwargs)
context['foo'] = 'MixinB'

return context


class SomeView(MixinA, MixinB, MyBaseView):
pass

# 

This is the correct solution. Try changing the order of the mixins in
SomeView to see the difference.


Cheers,
AT

[1] http://en.wikipedia.org/wiki/C3_linearization

On Tue, Jan 10, 2012 at 12:05 PM, jrief  wrote:

> But the mixin plugins are not derived from django.views.generic.DetailView,
> otherwise the main app's DetailView would obtain a diamond shaped
> inheritance.
>
> And django.views.generic.detail.BaseDetailView.get calls get_context_dataonly 
> once, so I don't see how the plugins shall "deliver" their contexts.
>
> BTW, I found another solution.
>
> Cheers, J.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/FpplXSO5pBYJ.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

really good !!

[Dana Woodman]

really good !!
i found a very good B2C place
really a good place for us
hope you can try too

enjoy yourself here

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[jrief]

Thank You, Roland, this was a good point to start with. I now found an 
elegant solution:

I added a base DetailView class for this project:

from django.views.generic import DetailView

class PluggableDetailView(DetailView):
def get_context_data(self, **kwargs):

context = super(PluggableDetailView, 
self).get_context_data(**kwargs)
for plugin in self.__class__.__bases__:
if hasattr(plugin, 'get_extra_context') and
 callable(plugin.get_extra_context):
context.update(plugin.get_extra_context(self, **kwargs))
return context

def post(self, *args, **kwargs):
for plugin in self.__class__.__bases__:
if hasattr(plugin, 'handle_post_request') and
 callable(plugin.handle_post_request):
plugin.handle_post_request(self, *args, **kwargs)

now I can add plug-ins and add two methods 

get_extra_context shall return a dict of extra context data merged together 
with the default context.

handle_post_request shall extract the plug-in specific post data and update 
the database or whatever else it must do.

The DetailView of the main app then inherits from PluggableDetailView, 
additional plug-ins can be mixed in, but no extra code has to be written to 
extend the context or to handle post requests.

class MainAppDetailView(PluggableDetailView, PluginAMixin, PluginBMixin):
pass
Does this approach make sense or did I reinvent the wheel?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/r_ZDUciOi6IJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[jrief]

But the mixin plugins are not derived from django.views.generic.DetailView, 
otherwise the main app's DetailView would obtain a diamond shaped 
inheritance.

And django.views.generic.detail.BaseDetailView.get calls get_context_dataonly 
once, so I don't see how the plugins shall "deliver" their contexts.

BTW, I found another solution.

Cheers, J.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/FpplXSO5pBYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Highlighting Active Navigation Link - correct approach?

[Matt Schinckel]

I have a reusable application I use for generating site-wide menu items. It 
does this (as well as dynamically showing/hiding menu items based on if the 
logged in user can access the view).

https://bitbucket.org/schinckel/django-menus

Actually, I think that was the one I put on pypi today, too.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/U3H0VIbAiW0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to mix in class based views from pluggable apps?

[Andre Terra]

Each plugin should call super() on their own definition of the
get_context_data method -- which will return a dictionary --, then update
and return a modified dictionary.

There's no need to explicitly call each plugin by the name in subclasses.
It works the other way around.


Cheers,
AT

On Tue, Jan 10, 2012 at 4:55 AM, Roland van Laar  wrote:

>  On 01/09/2012 10:36 PM, jrief wrote:
>
> Hi,
> currently I am writing a Django applications built up from loosely coupled
> plug-ins. Each of these plug-ins shall offer a class based view to handle
> get and post requests. For get requests the context shall be populated with
> plug-in specific data. For post requests, the plug-in specific posted data
> shall be handled by the corresponding view class.
>
>  This of course is not difficult to achieve. The view class of the final
> app, which combines all these plugins, can overload the methods
> get_context_data() and post() and dispatch the requests to functions
> offered by these plug-ins. But I do not like this approach because it does
> not separate concerns and the author of the final app has to remember, how
> to dispatch these requests manually to the plug-ins.
>
>
> Is there a way to know which plugin is needed?
>
>
>  My question is, if there is there a more elegant solution, say a
> pattern, which does not require to duplicate the dispatching code for the
> mixin classes?
>
>  Let me explain using some sample code:
>
>  class MainAppDetailView(SomeBaseDetailView, PluginAMixin, PluginBMixin):
>  model = MyModel
>  template_name = "my_detail.html"
>
>  def get_context_data(self, **kwargs):
> context = super(FinalAppDetailView,
> self).get_context_data(**kwargs)
> PluginAMixin(self).update_context(context)
> PluginBMixin(self).update_context(context)
>  return context
>
>  def post(self, *args, **kwargs):
> post_request = self.request.POST
>
> Instead of:
>
>  response = PluginAMixin(self).handle_post(post_request)
>  if issubclass(response, HTTPResponse):
>  return response
>  response = PluginBMixin(self).handle_post(post_request)
>   if issubclass(response, HTTPResponse):
> return response
>
> you could use:
>
> for plugin in (PluginAMixin, PluginBMixin):
> response = super(plugin, self).handle_post(post_request)
>
> if issubclass(response, HTTPResponse):
> return response
>
>
>
>   # handle post request for the main app
> ...
>  return response
>
>  For my point of view this example contains too much code duplication. Is
> there a pattern, so that I only have to modify the class declaration of my
> FinalAppDetailView or even better, only in my settings.py?
>
>  Cheers, Jacob
>  --
>
> Roland
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Need to examine and act on old vs. new at .save() time

[Andre Terra]

You can override the model's save method?[1][2]

Cheers,
AT


[1]
https://docs.djangoproject.com/en/dev/ref/models/instances/#saving-objects
[2]
https://docs.djangoproject.com/en/dev/topics/db/models/#overriding-model-methods


On Mon, Jan 9, 2012 at 11:39 PM, Jeff  wrote:

> Hi all,
>
> I need to be able to determine, at .save() time (before I call the
> parent class' .save()), if a certain field on my model object was
> changed, and act on that via some custom code.  How can I do this,
> bearing in mind that we call .save() from non-web code, etc?  We use
> Django's ORM from various other non-web interfaces and code.  My point
> is that we can't just inspect a web form's result data.
>
> I'd appreciate any thoughts.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

A demo of django-inlinetrans and django-inplaceedit

[J . Pablo Martín Cobos]

Hi,

I hope that you like the demo:

http://www.youtube.com/watch?v=_EjisXtMy_Y

Set full sscreen mode to view it correctly

Further information:

http://www.yaco.es/blog/en/contribuciones/2012/01/inline-editing-and-translating-in-django/

or Spanish version:

http://www.yaco.es/blog/contribuciones/2012/01/inline-editing-and-translating-in-django/

Regards,

--

Pablo Martín

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Need to examine and act on old vs. new at .save() time

[Jeff]

Hi all,

I need to be able to determine, at .save() time (before I call the
parent class' .save()), if a certain field on my model object was
changed, and act on that via some custom code.  How can I do this,
bearing in mind that we call .save() from non-web code, etc?  We use
Django's ORM from various other non-web interfaces and code.  My point
is that we can't just inspect a web form's result data.

I'd appreciate any thoughts.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[Solved] collectstatic missing on Linux

[Mike Dewhirst]

Thanks guys - I found the problem. It required the following in 
manage.py ...


import os, sys

if __name__ == "__main__":

SRC_ROOT = 
os.path.realpath(os.path.dirname(__file__)).replace('\\','/')

PROJECT_ROOT = os.path.split(SRC_ROOT)[0].replace('\\','/')

sys.path.append(PROJECT_ROOT)
sys.path.append(SRC_ROOT)

... for some reason manage.py doesn't like my Linux setup and needed 
some reassurance.


Cheers

Mike


On 10/01/2012 5:24pm, Jeff Heard wrote:

Make sure the staticfiles app is in your INSTALLED_APPS setting.
be my first guess.  If it is, do a manage.py console and try importing
it to make sure that the django environment can see it.

-- Jeff


On 10/01/2012 6:22pm, huseyin yilmaz wrote:

This is why linux is the best os. If anything goes wrong, you can
blame it on linux :)



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Directory layout for a large Django application (not project)

[Cal Leeming [Simplicity Media Ltd]]

I've hit this same problem myself many times.

Ultimately there is never any one answer - you can split out functionality
into individual modules, but there has to be a good use case for it,
otherwise the overhead has a negative impact.

You also have to take into consideration the re-usability of what you are
splitting out, and if something is split out, then it has to be treated as
a standardized module which is kept backwards compatible for everything.

It's not just a case of having a standardized directory layout, the entire
use case of the project will determine the layout - you can follow 'sane
principles' such as naming convention etc, but the actual splitting of
functionality is really up to the developer (and isn't really something
that can be taught - it's more of an experience thing).

Personally, I found that using 'MultiHostMiddleware' has been an absolute
life saver for splitting out sites within a single project - check it out:
http://code.djangoproject.com/wiki/MultiHostMiddleware (I just went and
tidied it up a bit).

Just my two cents worth!

Cal

On Tue, Jan 10, 2012 at 6:46 AM, Derek  wrote:

> Brian
>
> That is useful "generic" advice and a topic I am very interested in -
> how to break up an "enterprise" type of application into smaller apps
> (to enable distribution of sub-sections to different types of
> audiences) while at the same time maintaining tight coherency among
> closely-related data sets.  In this case there is a typically a "core"
> data set and then many other more peripheral ones that all need to
> connect to the core.  I have not yet seen any example of such a design
> process - or even a set of principles - which describe *how* to
> achieve such a design.
>
> Derek
>
> On 9 January 2012 18:18, Brian Schott  wrote:
> > My advice is If you find yourself breaking models, views, utils, etc.
> into separate files within an app, you should really consider breaking your
> app into multiple apps.  I hit this myself in or own project and found
> myself dealing with the auto registration functionality for admin.py,
> tasks.py, and a bunch of other too-large files.  I bit the bullet and broke
> things out and my import/discovery headaches disappeared.  My individual py
> files got small and
> >
> > +--major_app
> > +--docs
> > +--templates
> >  +-- (img, js, css, base.html)
> > +--projects
> >  +--dev
> >  +--test
> >  +--deploy
> > +--apps
> >  +--sub_app1(create with startapp command)
> >   +--models.py
> >   +--tasks.py
> >   +--templates
> >   +--tests.py
> >   +--urls.py
> >   +--views.py
> >   +--...
> >  +--sub_app2
> >   +-- .
> >
> > I put this in the top of my settings.py files down in projects/dev or
> projects/test, or projects/deploy so that the apps just get discovered.
> >
> > # the base directory is up two levels from the project
> > PROJDIR = os.path.abspath(os.path.dirname(__file__)) + '/'
> > PROJNAME = PROJDIR.split('/')[-2]
> > BASEDIR = os.path.abspath(os.path.join(PROJDIR, '..', '..')) + '/'
> > APPSDIR = os.path.abspath(os.path.join(BASEDIR, 'apps')) + '/'
> >
> > # add apps and projects directory to path
> > sys.path.insert(0, PROJDIR)
> > sys.path.insert(0, APPSDIR)
> >
> > Brian
> >
> > Brian Schott
> > bfsch...@gmail.com
> >
> > On Jan 7, 2012, at 2:24 PM, IgorS wrote:
> >
> >> Below is my current structure. I am new to Django and probably missing
> >> something... Restructuring an application somewhere in the middle of
> >> the development cycle is more expensive than just having the "right"
> >> layout from the start. Especially if this is possible. I consider a
> >> small overhead at the start being better than a great rework in the
> >> middle (yes, i am aware of the minimal viable product concept :-)
> >>
> >> app
> >>   +--models
> >>   ---abstract_base.py
> >>   ---core.py
> >>   ---...
> >>   +--probe
> >>   +--static
> >>   ---css
> >>   ---js
> >>   ---images
> >>   +--templates
> >>   ---base.html
> >>   ---...
> >>   +--tests
> >>   ---test_users.py
> >>   ---...
> >>   +--utils
> >>   +--views
> >>   ---__init__.py
> >>   ---app_settings.py
> >>   ---context_processors.py
> >>   ---middleware.py
> >>   ---urls.py
> >>
> >> Thank you,
> >> -igor
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed 

Re: Highlighting Active Navigation Link - correct approach?

[Ivo Brodien]

Hi,

strange that nobody answered yet since I guess that almost everybody 
encountered the same question already.

I personally did it via a custom template tag which puts out active if the 
current URL matches the URL pattern for a view.

Cheers
Ivo

On Jan 9, 2012, at 7:27 , Victor Hooi wrote:

> hi,
> 
> I have a project where I'm using Bootstrap (www.github.com/twitter/bootstrap) 
> with Django.
> 
> I need to add a CSS class ("active") to highlight the active navigation link.
> 
> Anyhow, I did some Googling:
> 
> http://www.turnkeylinux.org/blog/django-navbar
> http://ilostmynotes.blogspot.com/2010/03/django-current-active-page-highlighting.html
> http://gnuvince.wordpress.com/2007/09/14/a-django-template-tag-for-the-current-active-page/
> http://stackoverflow.com/questions/340888/navigation-in-django
> http://djangosnippets.org/snippets/1726/
> http://stackoverflow.com/questions/7665514/django-highlight-navigation-based-on-current-page
> 
> The approach in the above seems to be to either use custom template tag, 
> middleware or JS-hackery.
> 
> Is there a current consensus in the Django community in terms of what is the 
> "correct" approach for this?
> 
> Is there a reason something like this isn't part of Django core, or an 
> in-built templatetag?
> 
> Cheers,
> Victor
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/Xx5Rk_rBuxIJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.