Staticfiles on shared hosting using FCGI

2012-01-13 Thread Tundebabzy
I am stuck after running collectstatic. I don't know how to point the
server to STATIC_ROOT.
Can someone give assistance.

-- 
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: Help me with django Form

2012-01-13 Thread Python_Junkie
I believe you are mixing methods.

Django has built in generic views and generic forms for example.

But, you have used a template with standard (html) from syntax.

Since you are doing a post, request.

In your view just assign a variable to each variable in the form that
you are pulling back and then you can use those variables for the 2
functions that you wanted to achieve.

1. use the variables to insert a row into a database table
for example
names=request.names
etc

sql to insert into table
2. create a dcitionary to respond to the users request in the

[('names':names,   )]
 render_to_response('mainpage.html', dictionary values)


def welcome(request):
#Allow new user reg and login, if failed direct the user to
signup
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})

On Jan 14, 12:13 am, coded kid  wrote:
> Thanks guys! @daniel I still don't get what django doc is trying to
> say about ModelForm. Can you please explain further?
>
> On Jan 12, 10:30 am, Daniel Roseman  wrote:
>
>
>
>
>
>
>
> > On Thursday, 12 January 2012 01:49:40 UTC, coded kid wrote:
>
> > > Hi guys, I’ve been trying to signup using the django form I created.
> > > Whenever I signup, the form is always saving the id no and not other
> > > fields like names, username.pasword,email etc. Below are the codes;
> > > In views.py:
> > > from django.shortcuts import render_to_response
> > > from django.http import HttpResponse
> > > from django.template import RequestContext
> > > from django.http import HttpResponseRedirect
> > > from mymeek.meekme import models
> > > from django.views.decorators.csrf import csrf_exempt
> > > @csrf_exempt
> > > def welcome(request):
> > >     #Allow new user reg and login, if failed direct the user to signup
> > >     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})
>
> > You haven't defined a form. Just calling a model instance "form" doesn't
> > make it one.
> > Plus, of course, at no point are you passing the POST values into the
> > instantiation.
> > Seehttps://docs.djangoproject.com/en/1.3/topics/forms/modelforms/for
> > modelforms,
> > andhttps://docs.djangoproject.com/en/1.3/topics/forms/#using-a-form-in-a...
> > for the general pattern of how to instantiate a form from the POST.
> > --
> > DR.

-- 
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: Help me with django Form

2012-01-13 Thread coded kid
Thanks guys! @daniel I still don't get what django doc is trying to
say about ModelForm. Can you please explain further?

On Jan 12, 10:30 am, Daniel Roseman  wrote:
> On Thursday, 12 January 2012 01:49:40 UTC, coded kid wrote:
>
> > Hi guys, I’ve been trying to signup using the django form I created.
> > Whenever I signup, the form is always saving the id no and not other
> > fields like names, username.pasword,email etc. Below are the codes;
> > In views.py:
> > from django.shortcuts import render_to_response
> > from django.http import HttpResponse
> > from django.template import RequestContext
> > from django.http import HttpResponseRedirect
> > from mymeek.meekme import models
> > from django.views.decorators.csrf import csrf_exempt
> > @csrf_exempt
> > def welcome(request):
> >     #Allow new user reg and login, if failed direct the user to signup
> >     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})
>
> You haven't defined a form. Just calling a model instance "form" doesn't
> make it one.
> Plus, of course, at no point are you passing the POST values into the
> instantiation.
> Seehttps://docs.djangoproject.com/en/1.3/topics/forms/modelforms/for
> modelforms,
> andhttps://docs.djangoproject.com/en/1.3/topics/forms/#using-a-form-in-a...
> for the general pattern of how to instantiate a form from the POST.
> --
> DR.

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



accessing template context from inside a custom filter

2012-01-13 Thread Vovk Donets
Hello,

I want to make a filter with access to template context, like simple_tag
with takes_context=True

Is there a way do that?

-- 
*Vovk Donets*

-- 
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: admin list_filter: limit choices to model values?

2012-01-13 Thread Micky Hulse
Maybe simpler: Is there an easy way to limit the list_filter to folks
with "Superuser status"?

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



admin list_filter: limit choices to model values?

2012-01-13 Thread Micky Hulse
Hi.

Not sure where to start... Just hoping someone can give me a kick in
the right direction.

I have built a flat page app that allows for an author FK (optional field).

When I setup the admin to allow author as a list_filter, the actual
filter list of authors is way to long to be useful.

Would it be possible for me to setup my list_filter to only show
author names that have been assigned to my flat pages? For example,
let's say I have 10 pages, and two of those pages have the been FK'd
to "bjohnson" and "fjackson"... In my list_filter view, I would like
to only see "bjohnson" and "fjackson".

Does any of this make sense? :D

Any tips and/or advice would be awesome.

Thanks!
Micky

-- 
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: Class-Based Generic Views (CreateView) - field exclusions and defaults

2012-01-13 Thread Juergen Schackmann
you made my day, working exactly like expected.  :-)
thanks a lot

-- 
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/-/RUSugDsY9K0J.
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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Javier Guerra Giraldez
On Fri, Jan 13, 2012 at 4:03 PM, Stuart Laughlin  wrote:
> I don't construe that as Disqus officially preferring apache, but you
> are certainly entitled to your own interpretation.

right.  their commentary at the PyCon (from memory, i haven't checked
the video) was something like "why apache and not nginx or anything
else? well... it's the same thing. get over it"



-- 
Javier

-- 
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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Stuart Laughlin
On Fri, Jan 13, 2012 at 12:37 PM, Javier Guerra Giraldez
 wrote:
> On Fri, Jan 13, 2012 at 1:03 PM, Stuart Laughlin  
> wrote:
>> Just wanted to clarify that there are in fact some instructions out there
>> for options other than apache/mod_wsgi, even though mod_wsgi remains the
>> official preferred option ("If you’re new to deploying Django and/or Python,
>> we’d recommend you try mod_wsgi first. In most cases it’ll be the easiest,
>> fastest, and most stable deployment choice." [sic])
>
> and Disqus agrees with that.  check slide 14 of their 'Scaling
> Disqus'[1] presentation at PyCon2011
>
>
> [1]  http://www.slideshare.net/zeeg/pycon-2011-scaling-disqus-7251315
>

The slide you reference shows two graphs comparing apache + mod_wsgi
with nginx + uwsgi. The graphs demonstrate that according to their
tests the two are roughly equal in terms of requests-per-second and
memory size. They conclude that the application (not the web server)
is the bottleneck and recommend that people use what they're
comfortable with.

I don't construe that as Disqus officially preferring apache, but you
are certainly entitled to your own interpretation.


Regards,

--Stuart

-- 
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: Primary key for read-only models

2012-01-13 Thread Simone Federici
Try this:
https://github.com/simone/django-compositekey/wiki

and send me feedback :-)


On Thu, Jan 12, 2012 at 16:03, Demetrio Girardi
wrote:

> I need to read data from an "external" database table from my django
> project. I am not interested in modifying the data, only reading it.
> Of course I would like to create a django model for the table, because
> it makes life so much more easier.
>
> I have already done this previously, however in this case the table
> has a multiple field primary key, unsupported by Django. There is no
> other field which is guaranteed to be unique that I can use as primary
> key in the Django model.
>
> Do I need to worry about this? or can I just slap the primary_key flag
> on any of the fields, since I will never be inserting or updating in
> that table?
>
> --
> 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

2012-01-13 Thread Jeff
Remarkably, I've just today tripped over this same exact
problem again.  Turns out even using a post_save signal
callback function does not provide the information about
the new M2M data.

# callback for post_save signal, debug code removed for brevity
def ldap_netgroup_save(sender, **kwargs):
instance = kwargs['instance']
newng = kwargs['created']
cn = 'cn=%s,ou=Netgroup,%s' % (instance.name, base_dn)
connection = ldap.initialize(ldap_uri)
connection.simple_bind_s(bind_dn, bind_password)
if newng:
# WORKS
connection.add_s(cn, [('objectClass', 'nisNetgroup'),])
ifnames = []
for i in instance.interfaces.all():
ifnames = ifnames + make_nisnetgrouptriples(i.fqdn)
# HERE 'ifnames' is INCORRECTLY []
connection.modify_s(cn, [(ldap.MOD_REPLACE, 'nisNetgroupTriple',
ifnames),])

[NEW NETGROUP]*click*

Netgroup: foobar
Interfaces: I select 3
[SAVE]

DEBUG LOG:
Made new netgroup in LDAP: mynewnetgroup
saving interfaces as []

I view the netgroup in the admin interface and sure enough, all 3
'interfaces' are associated properly.

If I just click 'save' then it reports what it should
have reported when I made the new netgroup all along:

DEBUG LOG:
Existing netgroup in LDAP: mynewnetgroup
saving interfaces as ['(agilent,,)', '(agilent.our.org,,)',
'(ape,,)', '(ape.our.org,,)', '(aprh6test,,)',
'(aprh6test.our.org,,)']

This is such nonsense :(

On Jan 12, 12:20 pm, Jeff  wrote:
> On Jan 11, 9:23 pm, Dennis Lee Bieber  wrote:
>
> > On Wed, 11 Jan 2012 17:26:44 +, Tom Evans 
> > wrote:
>
> > >On Wed, Jan 11, 2012 at 5:22 PM, Jeff  wrote:
> > >> When Device.netgroups (a M2M field) changes, we need to perform
> > >> some python-ldap operations.
>
> > >Have you considered simply going back to the database to check what
> > >the values currently are? It would be inefficient, but clean and
> > >concise.
>
> >         I've forgotten how many means of changing this data there are,
> > but...
>
> Dennis,
>
> Several.
>
> A web-only solution won't work.
>
> I found the 'm2m_changed' signal yesterday, read that you can't
> determine *what* changed by using it, and also ended up directed
> to some open bug reports... etc... and threw up my hands.
>
> To the best of my digging, there is no way to accurately tell
> in SomeModel.save() whether the previous value of MyM2MField
> and the new value are the same, and/or what the differences
> are.
>
> I ended up completely restructuring stuff (I'll spare you the
> details) so that I can just say "whatever .netgroups looks
> like AFTER save, make LDAP look exactly like that."  This
> is essentially what Tom Evans suggested in his reply.  It's
> inefficient, and clearly a workaround, but is at least doable.
>
> It boils down in LDAP-terms to saying "replace all attribute
> values for X with the following full data.  I don't care what
> your old data was."  ... instead of saying, "remove value Y
> from the 1000 values set on X"  :|
>
> Thank you all for your efforts to 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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Javier Guerra Giraldez
On Fri, Jan 13, 2012 at 1:03 PM, Stuart Laughlin  wrote:
> Just wanted to clarify that there are in fact some instructions out there
> for options other than apache/mod_wsgi, even though mod_wsgi remains the
> official preferred option ("If you’re new to deploying Django and/or Python,
> we’d recommend you try mod_wsgi first. In most cases it’ll be the easiest,
> fastest, and most stable deployment choice." [sic])

and Disqus agrees with that.  check slide 14 of their 'Scaling
Disqus'[1] presentation at PyCon2011


[1]  http://www.slideshare.net/zeeg/pycon-2011-scaling-disqus-7251315


-- 
Javier

-- 
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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Stuart Laughlin
Having now looked more closely at the official deployment docs, I see they 
have been updated at some point to mention gunicorn and uwsgi, as well as 
nginx, cherokee, and lighttpd. So that's good. However, I also see that the 
deployment docs are a bit of a mess and could really use some love and 
attention, so there's some work to do there regardless.

Just wanted to clarify that there are in fact some instructions out there 
for options other than apache/mod_wsgi, even though mod_wsgi remains the 
official preferred option ("If you’re new to deploying Django and/or 
Python, we’d recommend you try *mod_wsgi* first. In most cases it’ll be the 
easiest, fastest, and most stable deployment choice." [sic])


--Stuart

-- 
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/-/0IBhJcetj4EJ.
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: Web Servers for Django Projects [WAS: Does anyone know any blogs...]

2012-01-13 Thread Stuart Laughlin
Tom, it seems to me that you and I are basically in agreement. What you are 
saying (correct me if I'm wrong) is that apache performs great and is a 
perfectly good option for django -- so long as you don't rely on stock 
versions and configurations. What I am proposing is that most django devs 
do just that. They are devs who want to get their apps out there quickly, 
not become apache experts. So they apt-get install apache, copy/paste the 
httpd.conf from the django docs, and they're done. If a django dev takes 
this same approach with nginx and gunicorn (for example) they are going to 
be better off than they would have been with apache/mod_wsgi.

But my other point, which you haven't addressed as much, is that apache is 
more difficult to troubleshoot when problems do arise. Because apache is a 
complex beast with lots of options and modules, it's very difficult for a 
non-expert to figure out where and why things have broken down. In my 
experience, the more simplistic servers are easier to troubleshoot (stands 
to reason, no?). I guess you are saying that this is no big deal because 
apache has a responsive and helpful support community, and that's fair 
enough, but I do think my point remains. After all, in spite of Graham 
coming through with The Perfect Config, I personally decided to not put 
myself through that experience again and moved away from apache on 
subsequent projects. I've been pleased with that decision, and I know many 
others share my experience.

So anyway, there are two aspects -- the performance/stability aspect where 
I reckon we are in essential agreement, and then there is the 
troubleshooting/diagnosing aspect where I am advocating that apache is more 
complicated than the lighter servers.


Hope that helps,

--Stuart



On Friday, January 13, 2012 10:04:42 AM UTC-6, Tom Evans wrote:
>
> On Fri, Jan 13, 2012 at 3:18 PM, Stuart Laughlin  
> wrote:
> > I hope you are not lumping me in with the relentless grudge-bearing
> > apache attackers. (After all, I've already been accused of ad hominem
> > attacks and some sort of fanboy me-too'ism on this thread [seriously
> > guys, is this a tough room or what?]). I have nothing against apache
> > per se -- it's a great server with a rich feature-set not found in the
> > lighter servers.  The only thing is, I don't want or need any of those
> > extra features for my django projects. So the only things those extra
> > features would contribute to my projects are additional complexity and
> > inefficiency. Servers like nginx, lighttpd, and cherokee were designed
> > specifically for people in this situation.
>
> I don't know what causes it, however this view - that lighty, nginx or
> cherokee are higher performing than Apache - is just nonsense. It gets
> rolled out whenever someone decides not to use Apache, and is without
> basis in fact. Apache is also designed for extremely light weight
> processes, if you configure it thus.
>
> [Side note - none of this is personal to you! I'm not trying to say
> that you are the fore-front of a horde of rabid anti-Apache-ism, it's
> just a common view that is propagated that really winds me up!]
>
> Apache covers almost every scenario related to HTTP, but commonly the
> particular version that a distro will package up is not necessarily
> the version that is correct for your particular scenario. Commonly, it
> will come with every bell and whistle enabled, and using a
> safe-but-slow request processing model, to accommodate mod_php.
>
> What happens is that someone who does not know how to use Apache uses
> the stock version supplied by their distro, leaves all features
> enabled, and then benchmarks it against lighty with a minimal
> configuration, and draws incorrect conclusions.
>
> It's similar to benchmarking a Mercedes with a manual transmission
> against a Ford with an automatic transmission, driving the Mercedes
> only in first gear and concluding that the Ford is faster.
>
> > I'm not concerned with micro-performance enhancements. Nginx is
> > clearly more efficient and performant than apache, but my main concern
> > is being able to diagnose problems when they arise. I used apache/
> > mod_wsgi for my first few production deployments, and it was a very
> > unpleasant experience -- weird memory usage statistics, users getting
> > intermittent error messages, etc. -- and tracking down the problem was
> > basically impossible. I found apache to be an opaque black box. The
> > only thing that saved me was Graham Dumpleton sweeping in to rescue me
> > with the perfect mod_wsgi config. He's the killer feature of django on
> > apache as far as I'm concerned.
> >
>
> Memory usage is one of the more common non-complaints aimed at Apache.
> Apache does not usually leak memory, and process sizes normally stay
> consistent for long long periods. The only time this does not happen
> is when you embed a language interpreter and application inside
> Apache, and that leaks. This is typical when running 

Re: Web Servers for Django Projects [WAS: Does anyone know any blogs...]

2012-01-13 Thread Tom Evans
On Fri, Jan 13, 2012 at 3:18 PM, Stuart Laughlin  wrote:
> I hope you are not lumping me in with the relentless grudge-bearing
> apache attackers. (After all, I've already been accused of ad hominem
> attacks and some sort of fanboy me-too'ism on this thread [seriously
> guys, is this a tough room or what?]). I have nothing against apache
> per se -- it's a great server with a rich feature-set not found in the
> lighter servers.  The only thing is, I don't want or need any of those
> extra features for my django projects. So the only things those extra
> features would contribute to my projects are additional complexity and
> inefficiency. Servers like nginx, lighttpd, and cherokee were designed
> specifically for people in this situation.

I don't know what causes it, however this view - that lighty, nginx or
cherokee are higher performing than Apache - is just nonsense. It gets
rolled out whenever someone decides not to use Apache, and is without
basis in fact. Apache is also designed for extremely light weight
processes, if you configure it thus.

[Side note - none of this is personal to you! I'm not trying to say
that you are the fore-front of a horde of rabid anti-Apache-ism, it's
just a common view that is propagated that really winds me up!]

Apache covers almost every scenario related to HTTP, but commonly the
particular version that a distro will package up is not necessarily
the version that is correct for your particular scenario. Commonly, it
will come with every bell and whistle enabled, and using a
safe-but-slow request processing model, to accommodate mod_php.

What happens is that someone who does not know how to use Apache uses
the stock version supplied by their distro, leaves all features
enabled, and then benchmarks it against lighty with a minimal
configuration, and draws incorrect conclusions.

It's similar to benchmarking a Mercedes with a manual transmission
against a Ford with an automatic transmission, driving the Mercedes
only in first gear and concluding that the Ford is faster.

> I'm not concerned with micro-performance enhancements. Nginx is
> clearly more efficient and performant than apache, but my main concern
> is being able to diagnose problems when they arise. I used apache/
> mod_wsgi for my first few production deployments, and it was a very
> unpleasant experience -- weird memory usage statistics, users getting
> intermittent error messages, etc. -- and tracking down the problem was
> basically impossible. I found apache to be an opaque black box. The
> only thing that saved me was Graham Dumpleton sweeping in to rescue me
> with the perfect mod_wsgi config. He's the killer feature of django on
> apache as far as I'm concerned.
>

Memory usage is one of the more common non-complaints aimed at Apache.
Apache does not usually leak memory, and process sizes normally stay
consistent for long long periods. The only time this does not happen
is when you embed a language interpreter and application inside
Apache, and that leaks. This is typical when running with mod_wsgi
embedded mode, and I would guess that Graham had you change your setup
to daemon mode.

I would also say that Apache is a complex beast - there are lots of
options and modules. It also has a very responsive and helpful support
community. If anyone using Django needs help with any aspect of
Apache, try us...@httpd.org .

Cheers

Tom

PS: I would agree that Graham is one of the top features of Apache :)
His mod_wsgi is excellent, and his support for Django is very
admirable, given that (IIRC) he doesn't actually use it himself much!

-- 
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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Andre Terra
nginx runs on windows xp, and should run on vista/7 too.

I've even managed to compile a version on cygwin with an additionally
patched module that allows for file upload progress tracking.

If anyone wants it, i can put it on github with a sample .conf file, but no
strings attached at all.


Cheers,
AT

On Fri, Jan 13, 2012 at 1:36 PM, Stuart Laughlin wrote:

> On Jan 12, 9:16 pm, Andres Reyes  wrote:
> > You mean that the webserver that Django itself recommends in
> https://docs.djangoproject.com/en/dev/howto/deployment/is not a good
> > choice?
> >
>
> When that documentation was written, apache/mod_wsgi was likely the
> best, easiest, and most stable option. That combination still works
> today and many people use it successfully. To that extent, it is a
> good choice.
>
> However, I am saying it is not the best choice anymore -- at least not
> for people who are just getting started and/or people who lack prior
> apache experience. In this case I would recommend nginx or lighttpd or
> cherokee for the web server and gunicorn or uwsgi for the application
> server. By this time they are stable, and they are faster and easier
> than apache/mod_wsgi.
>
> I wrote more about this in a reply to this thread where I changed the
> subject to "Web Servers for Django Projects".
>
> If I recall correctly, I have heard some of the core devs mention
> updating the docs to include some of these other options. I wonder if
> anyone has submitted a patch for those doc updates. If not, maybe I've
> found my weekend project.
>
> A final thought that I did not consider until just now -- cross-
> platform compatibility might be a factor. I use linux for everything,
> so that's all I care about. To be frank I have no idea whether nginx /
> lighttpd / cherokee / gunicorn / uwsgi run on Windows or Mac. If they
> do not then that can tend to complicate the docs somewhat.
>
>
> --Stuart
>
> --
> 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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Stuart Laughlin
On Jan 12, 9:16 pm, Andres Reyes  wrote:
> You mean that the webserver that Django itself recommends in 
> https://docs.djangoproject.com/en/dev/howto/deployment/is not a good
> choice?
>

When that documentation was written, apache/mod_wsgi was likely the
best, easiest, and most stable option. That combination still works
today and many people use it successfully. To that extent, it is a
good choice.

However, I am saying it is not the best choice anymore -- at least not
for people who are just getting started and/or people who lack prior
apache experience. In this case I would recommend nginx or lighttpd or
cherokee for the web server and gunicorn or uwsgi for the application
server. By this time they are stable, and they are faster and easier
than apache/mod_wsgi.

I wrote more about this in a reply to this thread where I changed the
subject to "Web Servers for Django Projects".

If I recall correctly, I have heard some of the core devs mention
updating the docs to include some of these other options. I wonder if
anyone has submitted a patch for those doc updates. If not, maybe I've
found my weekend project.

A final thought that I did not consider until just now -- cross-
platform compatibility might be a factor. I use linux for everything,
so that's all I care about. To be frank I have no idea whether nginx /
lighttpd / cherokee / gunicorn / uwsgi run on Windows or Mac. If they
do not then that can tend to complicate the docs somewhat.


--Stuart

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



Web Servers for Django Projects [WAS: Does anyone know any blogs...]

2012-01-13 Thread Stuart Laughlin
On Jan 13, 5:01 am, Tom Evans  wrote:
> On Thu, Jan 12, 2012 at 11:32 PM, Stuart Laughlin  
> wrote:
> > I don't care a whit about what "the cool boys" are doing. What I care about
> > is a production deployment that works efficiently and reliably and that is
> > diagnosable when something doesn't work. Apache fails those criteria; nginx
> > and lighttpd pass (in my opinion and the opinion of many other developers
> > who have used these technologies for non-trivial web applications in
> > production environments).
>
> Despite the relentless attacks from people who have some sort of
> grudge against Apache, I'd remind any readers that Apache is the most
> used and trusted web server on the internet. It forms an integral part
> of the technology that the company I work for is built around, and
> performs extremely well for our usage, and I would thoroughly
> recommend it.
>

You can certainly demonstrate that Apache is the most used web server
(57% and declining according to the most recent numbers I've seen).
"Most trusted" is questionable, being such a subjective quality, but
that's just a quibble. If apache forms an integral part of the
technology that your company uses, then obviously it makes sense for
you to use apache. Many people in this forum have no such investments
in apache and have no idea how to tune/configure it optimally. In that
case, I believe using apache is a mistake.

I hope you are not lumping me in with the relentless grudge-bearing
apache attackers. (After all, I've already been accused of ad hominem
attacks and some sort of fanboy me-too'ism on this thread [seriously
guys, is this a tough room or what?]). I have nothing against apache
per se -- it's a great server with a rich feature-set not found in the
lighter servers. The only thing is, I don't want or need any of those
extra features for my django projects. So the only things those extra
features would contribute to my projects are additional complexity and
inefficiency. Servers like nginx, lighttpd, and cherokee were designed
specifically for people in this situation.

> Besides which, arguing about which web server is more efficient is a
> clear indicator that you are concentrating on the wrong areas. nginx
> or lighthttpd vs apache is meaningless when your the bottleneck will
> always be the python application and/or DB server.
>

I'm not concerned with micro-performance enhancements. Nginx is
clearly more efficient and performant than apache, but my main concern
is being able to diagnose problems when they arise. I used apache/
mod_wsgi for my first few production deployments, and it was a very
unpleasant experience -- weird memory usage statistics, users getting
intermittent error messages, etc. -- and tracking down the problem was
basically impossible. I found apache to be an opaque black box. The
only thing that saved me was Graham Dumpleton sweeping in to rescue me
with the perfect mod_wsgi config. He's the killer feature of django on
apache as far as I'm concerned.

I hope this helps to clarify my comments regarding apache and why
someone who is not already an apache expert might wisely choose
something other than apache to serve their django projects.


--Stuart

-- 
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: restricting choices of foreign key to objects owned by user

2012-01-13 Thread Kevin
You will need to alter the methods for the AdminModel:

https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.queryset

Your main focus will be the queryset method to limit what users can
see, this should also limit drop down boxes as well.  You may also
want to look at the formfield_for_* methods as well:

https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_for_foreignkey

These would be your starting point, there is also the permission ones
as well, which I do believe will limit the views using permissions.

On Jan 12, 6:17 am, kenneth gonsalves  wrote:
> hi
>
> note: this is in admin.
> I have a model called Child. Child has foreign key to Project. There are
> many projects, but each user is only allowed to add a child to the
> projects he belongs to. I have restricted the ProjectAdmin queryset so
> that the user can only see his projects in the project changelist. But
> when the user goes to add/edit a child, the dropdown shows *all*
> projects and not only the projects he belongs to. Any clues on how to
> achieve this?
> --
> 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.



Re: How to avoid "no such column" error when I add a new property to a model?

2012-01-13 Thread David Harks
On Jan 11, 2012, at 4:26 AM, callum  wrote:

> I created an "Article" model with a few simple properties. I ran
> syncdb, and set up the Django admin site, and added
> "admin.site.register(Article)" in admin.py. Using the Django admin
> site, I created an article by filling in the form.
>
> I then went into models.py and added another property. I ran syncdb
> again, ran the server again, then when I opened the Django admin site
> again, I got the "no such column" error.
>
> When I Googled this, the only obvious solutions I found were to reset
> the app, or at least drop the database table that changed, and start
> over.
>
> But how do I do this without losing my data?
>

Check out South. http://south.aeracode.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: Does anyone know any blogs that write about how to quickly install and deploy a django application on Amazon EC2?

2012-01-13 Thread Tom Evans
On Thu, Jan 12, 2012 at 11:32 PM, Stuart Laughlin  wrote:
> I don't care a whit about what "the cool boys" are doing. What I care about
> is a production deployment that works efficiently and reliably and that is
> diagnosable when something doesn't work. Apache fails those criteria; nginx
> and lighttpd pass (in my opinion and the opinion of many other developers
> who have used these technologies for non-trivial web applications in
> production environments).

Despite the relentless attacks from people who have some sort of
grudge against Apache, I'd remind any readers that Apache is the most
used and trusted web server on the internet. It forms an integral part
of the technology that the company I work for is built around, and
performs extremely well for our usage, and I would thoroughly
recommend it.

Besides which, arguing about which web server is more efficient is a
clear indicator that you are concentrating on the wrong areas. nginx
or lighthttpd vs apache is meaningless when your the bottleneck will
always be the python application and/or DB server.

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: change min_length in form __init__?

2012-01-13 Thread Alasdair Nicol

On 13/01/12 10:47, bruno desthuilliers wrote:

On Jan 11, 12:15 pm, galgal  wrote:

Is there any way, to change the field's *min_length* argument inside form
constructor? That doesn't work:

def __init__(self, *args, **kwargs):
 super(CreateTeamForm, self).__init__(*args, **kwargs)
 self.fields['primary_color'].min_length = 4

Assuming primary_color is a CharField, this should theoretically
JustWork AFAICT. What is the result ? ("doesn't work" is not really
descriptive...)


Hi Bruno,

I answered this question on Stack Overflow earlier this week [1].

When a field with min_length is initialised, a MinLengthValidator is 
added to the its validators. So if you set the min_length attribute 
after calling parent classes __init__ method, it is 'too late' for it to 
have any effect.


The solution is to change the field's validators in the __init__ method 
instead,


Cheers,
Alasdair

[1]: 
http://stackoverflow.com/questions/8818261/django-change-min-length-in-form-init/


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

--
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: change min_length in form __init__?

2012-01-13 Thread bruno desthuilliers
On Jan 11, 12:15 pm, galgal  wrote:
> Is there any way, to change the field's *min_length* argument inside form
> constructor? That doesn't work:
>
> def __init__(self, *args, **kwargs):
>     super(CreateTeamForm, self).__init__(*args, **kwargs)
>     self.fields['primary_color'].min_length = 4

Assuming primary_color is a CharField, this should theoretically
JustWork AFAICT. What is the result ? ("doesn't work" is not really
descriptive...)

-- 
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: change min_length in form __init__?

2012-01-13 Thread bruno desthuilliers
On Jan 13, 7:02 am, Wen 温业逵Yekui  wrote:
> why you use the "*" in your function argument?
>
Because it's the sensible thing to do here - cf
http://docs.python.org/release/2.6.7/tutorial/controlflow.html#more-on-defining-functions


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

2012-01-13 Thread J . Pablo Martín Cobos
2012/1/12 Juergen Schackmann 

>
>
>>
>>
>>> 2. If I do not want to send field by field, but possibly a set of fields
>>> back to the to the server, like the row of a table. Would that be feasible?
>>>
>>
>> Now this is not implemented, and I think it is not trivial. But you can
>> try it
>>
> i am afraid my js skills are too limited for that :-(
>

If you change the backend to allow edit inplace of various fields, I change
the fronted, although I don't need this feature :-)


>
>> 3. How would you create a new field on the page/ new object in the model?
>>>
>>
>> I'm sorry I don't understand this
>>
> let me explain with an example: i have an recipe model and i have
> ingredients that have a foreign key to recipe.  on the web page i display
> the recipe plus all its ingredients. and with inplaceedit i can edit all
> those ingredients, which is great. but how would i enable the user to add a
> new ingredient?
>
>

Ok now I understand.

Now this is not possible, when dealing with relationships you can only
inplace edit using fk and m2m. But it is not difficult to implement in
django-inplaceedit.

You should create a adaptor

http://tracpub.yaco.es/djangoapps/browser/inplaceeditform/trunk/inplaceeditform/fields.py#L305

and add a condition:

http://tracpub.yaco.es/djangoapps/browser/inplaceeditform/trunk/inplaceeditform/commons.py#L57

I paste of the post in the blog [1]:

"Should be generic, configurable and extensible"

"It is important to notice that neither the inline edition or translation
cannot replace an administration of content or tags, but they can greatly
improve user experience."

REF's

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

I hope your questions have been resolved

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



Web application in high demand

2012-01-13 Thread Kevin
I am getting ready to put together a Django web application portfolio,
but first I am doing some research on which apps I will build for the
portfolio itself to show off to possible employers.

Is there an online resource which lists the top requests web
applications?  I did a google search and only found results for the
higher demanding languages.  I am making this portfolio language
transparent, where what matters most is the end product and not what
is used to build that product.

I know social type apps and sites are in high demand, but that is a
little broad, like which kind of social apps and sites are in high
demand?  Is there demand for collaboration web applications?  What are
businesses currently seeking web developers to build for them, for
either internal or public consumption?

A site similar to TIOBE would be nice, but I highly doubt a company is
going through this effort.

Thanks.

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



list_filter not showing up in admin

2012-01-13 Thread The Ape
Hi everyone,

I am quite new to delevoping with django and I am trying to setup a
simple blog app.
I wanted to use a "list_filter" in the admin but it is somehow not
showing up at all...
I am using django 1.3 and python 2.7.1. (The models are listed
below...)

Does anyone have a suggestion how to make it work?

Thank you for help in advance!


The model:

class Post(models.Model):
author = models.ForeignKey(User, related_name='posts')
title = models.CharField(max_length=255)
body = models.TextField()
pub_date = models.DateTimeField(auto_now_add=True)
edit_date = models.DateTimeField(auto_now=True)
is_public = models.BooleanField('public', default=False)

class Meta:
order_with_respect_to = 'author'
get_latest_by = 'pub_date'
ordering = ['-pub_date']

def __unicode__(self):
return self.title


The admin model:

class PostAdmin(admin.ModelAdmin):
readonly_fields = ['pub_date', 'edit_date']
fieldsets = [
 (None, {'fields': ['author', 'title',
'body', 'is_public']}),
 ('Date information',   {'fields': ['pub_date',
'edit_date']})
]
list_display = ['title', 'author', 'pub_date']
list_filer = ['is_public']
ordering = ['-pub_date']
search_fields = ['title']

-- 
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: Internationalization and localization

2012-01-13 Thread Daniel Gerzo

On Tue, 6 Dec 2011 16:40:42 -0800 (PST), rentgeeen wrote:


But what I want to achieve is if I give somebody link:

it/sample/
en/sample/

it will show that page in that language, now I have to choose 
language

and then go to the page and see it in that language...


you need django 1.4 and i18n_patterns:
https://docs.djangoproject.com/en/dev/topics/i18n/translation/#django.conf.urls.i18n.i18n_patterns

--
S pozdravom / Best regards
  Daniel

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