Re: models and NULL in postgres

[Donald Stufft]

Django uses an empty string instead of a NULL for an empty value for CharField 
and Charfield subclasses 


On Thursday, March 15, 2012 at 10:18 PM, hack wrote:

> Something is a little strange with my database.  My models have fields where 
> the value is set as blank=True to allow null values.  My forms seem to be 
> saving values to the database just fine, even if the are blank/null.  
> However, when I look at my database in phppgadmin all the rows show they are 
> set as NOT NULL, which implies they should not allow null values to be saved. 
>  Is there some bug with django and postres, which I am not aware of?  Maybe 
> just a bug in phppgadmin.  Thanks. 
> 
> -- 
> 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/-/WPIOw8u8trkJ.
> 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: Why can't forms access the request object?

[Donald Stufft]

On Sunday, March 11, 2012 at 12:43 PM, shacker wrote:
> On Sunday, March 11, 2012 6:24:30 AM UTC-7, skhohlov wrote:
> > Of course form  does not have access to the object. 
> 
> 
> skholov - Thanks, but you misunderstand my question. Again, I know that forms 
> don't have access to request, and again, I've got it working already (though 
> with a different approach - see my OP). My question was an attempt to 
> understand the plumbing or the python better. To reiterate, I'd like to know 
> WHY request isn't automatically available from forms, as it is from views. To 
> put the question another way, when we define a view function, we do something 
> like:
> 
> def edit(request,story_id):
>   ...
This is a function that get's passed request as it's first argument. Since view 
functions are _always_ run during the request response cycle of an HTTP 
request, request is always available to be passed into the view. 
> 
> But when we create a form, we can't just do:
> 
> class StoryForm(ModelForm, request):
>   ...
> 
> 

This is subclassing the form from request. the equivalent code would be to 
accept the request in the forms __init__, 
however this would need to be option to still allow using the forms outside of 
the request, response cycle. This parameter
is very easy to add on your own and including it by default needlessly ties the 
form processing library to django requests.
> 
> It seems like this is the kind of thing Django could take care of for us - we 
> shouldn't have to jump through hoops to get at request -  but there's 
> probably a good reason why it works this way. Does my question make more 
> sense now? 
> 
> Thanks,
> Scot
> 
> -- 
> 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/-/8DXqXSX-YhAJ.
> 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: Why can't forms access the request object?

[Donald Stufft]

Forms aren't only usable from inside a view. 


On Sunday, March 11, 2012 at 4:32 AM, shacker wrote:

> I recently needed to access request.user in a form, and found that I 
> couldn't. Found many articles describing ways to accomplish this, such as 
> James Bennett's [1].
> 
> I did get it working, but I'm curious *why* the request object isn't 
> accessible from forms as it is from views. Why do we need to override 
> __init__  to accomplish this? Seems like the kind of thing Django could "take 
> care of" for us.
> 
> [1] http://www.b-list.org/weblog/2008/nov/09/dynamic-forms/
> 
> Thanks to anyone who can clarify.
> 
> ./s
> 
> 
> 
> -- 
> 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/-/1z9ElVqpRucJ.
> 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: Homakov-esque Django Vulnerabilities

[Donald Stufft]

On Tuesday, March 6, 2012 at 7:11 PM, Russell Keith-Magee wrote:
> 
> On 07/03/2012, at 7:55 AM, Joey Espinosa wrote:
> 
> > I agree with you on some of your points. Security can be improved if people 
> > would email the support team INSTEAD OF filing a bug report (this goes for 
> > any project), so that the teams know about security bugs before anybody 
> > else finds them.
> > 
> > However, if there's a default setting or commonly set configuration choice 
> > that may be questionable for security, the best course of action would be 
> > to educate the Django developers and site maintainers on why it is or is 
> > not a good idea to implement. The Rails community has mentioned the Homakov 
> > vulnerability to the Rails team, to which their stance has been 
> > configuration over convention (you're responsible for your own security).
> > 
> > If there's a similar situation with the Django code, and it's something 
> > that's been put in intentionally by the Django team, then why not educate 
> > people about this? Better to have a resource somewhere where at least one 
> > Django developer on a team might have read a good security tip and share it 
> > with his team, than to have a potential attacker figure it out and exploit 
> > all of the Django sites that may have overlooked it. To put it in real life 
> > terms, you don't combat identity theft by not talking about it, you combat 
> > it by providing resources to educate the general public about how to 
> > protect themselves.
> 
> Completely agreed that then education is key. However, the key statement in 
> your reply is "something that's been put in intentionally by the Django 
> team". 
> 
> All I'm asking is before anyone starts broadcasting details about a 
> "vulnerability", that they take the time to contact the core team on 
> secur...@djangoproject.com (mailto:secur...@djangoproject.com) to determine 
> whether the code and it's side effects actually *are* intentional. You 
> *might* have discovered something that has been done intentionally, with full 
> knowledge of the consequences. It *might* be a case where we need to rely on 
> education -- improve Django's own docs, and encourage people like yourself to 
> blog about how to "do it right". However, it might also be a case where we 
> hadn't fully considered all the consequences, in which case, we'd like the 
> opportunity to address the problem before it becomes widespread public 
> knowledge.
> 
> In short -- err on the side of caution. It costs nothing to mail 
> secur...@djangoproject.com (mailto:secur...@djangoproject.com). If you have 
> found a serious problem, we'll give credit where it's due. If not, we'll let 
> you know you can start educating the world about what they're doing wrong.
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> 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.
> 
> 

For what it's worth in the context of the Homakov exploit, this has been a well 
known vulnerability by the rails core for years
that they've basically said "not our problem, configure your app better" the 
entire time. I think that situation is the one that
Joey was referring too. 

-- 
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: I need a package.

[Donald Stufft]

https://github.com/eldarion/user_messages 


On Friday, February 3, 2012 at 3:16 AM, coded kid wrote:

> Anyone knows about a django package that can be use by users to send
> private messages to each other?


-- 
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: Social conference website?

[Donald Stufft]

There's https://github.com/pinax/symposion but i'm not sure what you mean by 
"social".

On Thursday, January 12, 2012 at 1:18 PM, Alec Taylor wrote:

> Good morning,
>  
> I am building up a social-conference website in Django for a
> university clubs' comedy-revue.
>  
> I will open-source it under the two-clause BSD license.
>  
> Features I would like to implement:
> • User accounts automatically generated on attendance registration
> • Ticket, Sponsor and paraphernalia sales through a PayPal gateway
> • Document collaboration area (built off askbot) for Writers
>  
> I have seen a variety of Django-based conference websites. Which would
> you recommend I build off to ascertain the aforementioned features?
>  
> Thanks for all suggestions,
>  
> Alec Taylor
>  
> --  
> 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)

[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: Interface implementation in python

[Donald Stufft]

Why not use zone.interface

On Wednesday, January 4, 2012 at 7:07 AM, huseyin yilmaz wrote:

> Hi everybody,
> 
> I want to implement interface functionality in python. I wrote
> following sample code
> 
> https://gist.github.com/1559689
> 
> Here I use an abc as an interface.
> Couple of my models are implementing this interface and one of my
> consumer model is using those models. In this implementation, I use my
> abstract class to check if my models are implementing enough
> functionality to make consumer model methods work (use_object method).
> 
> Since I used abc's here, I get an error as soon as I try to
> instantiate a model object. (I do not need to invoke use_object method
> for validation to work.)
> 
> Question 1) Is there a better way to implement this validation
> functionality.
> Question 2) In this implementation, Validation happens at object
> instantiation time. Which means If I don't instantiate any object I
> won't get any error, Is there a ( short ) way of getting this check on
> code initialization? ( I am not dynamicly changing methods of my
> models)
> 
> 
> -- 
> 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: {% elif %} error

[Donald Stufft]

Or back port the elif tag (which may or may not be non trivial).

On Wednesday, December 28, 2011 at 1:50 AM, Russell Keith-Magee wrote:

> On Wed, Dec 28, 2011 at 2:44 PM, Tsung-Hsien  (mailto:jasoniem9...@gmail.com)> wrote:
> > Hi,
> > I want to use {% elif %}
> > my template:
> >{% if bookmark.hours %}
> >{{ bookmark.hours }} hours ago
> >{% elif bookmark.days %}
> >{{ bookmark.days }} days ago
> >{% elif bookmark.months %}
> >{{ bookmark.months }} months ago
> >{% else %}
> > {{ bookmark.years }} years ago
> >{% endif %}
> > 
> > 
> > show error:
> > Invalid block tag: 'elif', expected 'else' or 'endif'
> > 
> > It can work without elif, if use if...else loop.
> > 
> > my django version is 1.31
> > 
> > how to solve this?
> 
> The {% elif %} tag was only recently added to Django; it will be
> available in the 1.4 release. Django 1.3 and earlier does not, and
> will not ever contain the {% elif %} tag.
> 
> You can either develop your site against Django's trunk in the hope
> that Django will release 1.4 before you need to roll out your site, or
> modify your template to use nested {% if %} statements.
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> 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: DoS susceptability via email logging

[Donald Stufft]

On Thursday, December 8, 2011 at 7:33 PM, Russell Keith-Magee wrote:
> On Thu, Dec 8, 2011 at 8:42 PM, Sam Berry  (mailto:samkbe...@googlemail.com)> wrote:
> > Hello there,
> > 
> > I am currently running a number of small sites using logging via email
> > to notify me of 404s and server errors. The volume of email produced
> > is perfectly manageable due to the low level of traffic.
> > 
> 
> 
> First off, I'd point out that the 404 emails aren't sent every time
> your server generates a 404 -- they're only generated as a result of a
> 404 *from an internal link on your site*. If John Q Hacker hits
> http://yoursite.com/this_page_doesnt_exist, you won't get a 404 email.
> 
> 

This isn't exactly accurate. It sends them for any 404 response where the 
HTTP_REFERER
header is not in the ignorable urls setting, is not empty, and does not contain 
a ?

This is also trivial to get around and if someone is attempting to trigger a 
boatload of
404 emails this check is only going to prevent someone who knows nothing about 
Django (in
which case how do they know about 404 email sending?). 
> 
> If you're getting *any* 404 emails, it means there are internal links
> on your site that don't resolve. If this is something that is
> happening systematically, at a rate that has given you cause for
> concern about the potential for DOS, I'd suggest you have a bigger
> problem with your site.
> 
> > It does occur to me that it would be very easy to disrupt the site by
> > simply sending repeated requests which trigger a 404 Not Found. I'm
> > sure 10 404s a second would completely shutdown the process to normal
> > requests due to the time taken to send the log emails. I'm not using a
> > message queueing system.
> > 
> > I would like to keep the option of receiving logging emails. Is there
> > anything I can do to throttle or limit the email sending without
> > writing my own logging handler?
> > 
> 
> 
> Interestingly, 404 emails aren't handled by a logging handler (unlike
> 500 messages) -- they're handled as a direct mail to site managers.
> This is something that is probably worth a ticket in itself; using the
> logging framework for 404 mails would allow for much more flexibility.
> 
> 

Agreed, 404 should be configurable via Logging. 
> 
> So - what you want here isn't a custom logging handler, but a custom
> *mail* handler -- django-mailer [1] is a good candidate here. This
> makes "sending" an email a very short lived operation from the
> perspective of your web server -- all the web request does is queue
> the email for sending. The actual sending of mail is handled out of
> the request-response cycle. This removes the possibility of "DOS
> attack by 404" because the expensive operation is taken out of the
> request-response cycle.
> 
> 

This is True.  You could also move email sending to a celery task
or something similar.
> 
> Of course, you could still end up being flooded with email -- so you
> either need to (a) monitor the size of your mail queue to make sure it
> isn't getting flooded, or (b) put a processor in place to
> merge/throttle the contents of the mail queue. This could also be
> handled with a custom mail handler; however, I can't point you at a
> ready-to-use candidate for this.
> 
> Another option is to use a mechanism other than the 404 emails to log
> and handle errors. Django-sentry [2] and Arecibo [3] are two
> candidates here, both of which are easy to install, and provide much
> richer analytics than a full mailbox :-)
> 
> 

This is, in my opinion, the best option if you wish to track 404's. 
> 
> [1] https://github.com/jtauber/django-mailer/
> [2] https://github.com/dcramer/django-sentry/
> [3] http://areciboapp.com/
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> 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: filesystem path in settings.py

[Donald Stufft]

The static files app doesn't serve static files (except in development).

What it's primary purpose is to take a list of "finders", and locate all of the 
static files from a variety of places, and collect them into one directory. 
This allows reusable apps to package static files within their apps, and then 
have those files available automatically. The alternative is basically include 
as part of the installation instructions "symlink this folder", or "copy these 
files", or "make sure you download these" etc. 


On Thursday, December 8, 2011 at 7:24 PM, Timothy Makobu wrote:

> Hi Tanya,
> 
> Also have a look at this 
> https://docs.djangoproject.com/en/dev/howto/static-files/#serving-static-files-in-production
>  
> 
> I personally leave Django out of static file serving entirely, and have the 
> webserver serve the static media, but I'll experiment and see what advantage 
> there is to using the staticfilesapp.
> 
> 
> On Sun, Dec 4, 2011 at 11:01 AM, Timothy Makobu  (mailto:makobu.mwambir...@gmail.com)> wrote:
> > In Django 1.3:
> > 
> > STATIC_ROOT = os.path.join(os.path.dirname(__file__), 
> > 'static').replace('\\','/')
> > 
> > where the folder "static" is in the root of your project folder. 
> > 
> > 
> > On Sun, Nov 27, 2011 at 2:23 PM, TANYA  > (mailto:tani...@gmail.com)> wrote:
> > > I read it but after following all steps in it the error still remains.
> > > 
> > > '/usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg',
> > > '/usr/lib/python2.6',
> > > '/usr/lib/python2.6/plat-linux2',
> > > '/usr/lib/python2.6/lib-tk',
> > > '/usr/lib/python2.6/lib-old',
> > > '/usr/lib/python2.6/lib-dynload',
> > > '/usr/local/lib/python2.6/dist-packages',
> > > '/usr/lib/python2.6/dist-packages',
> > > '/usr/lib/python2.6/dist-packages/PIL',
> > > '/usr/lib/pymodules/python2.6',
> > > '/usr/lib/pymodules/python2.6/gtk-2.0',
> > > '/usr/lib/python2.6/dist-packages/wx-2.6-gtk2-unicode'I did symlink to 
> > > /usr/bin/local but still get path error. Please help.
> > > 
> > > 
> > > 
> > > On Fri, Nov 25, 2011 at 4:44 AM, Timothy Makobu 
> > >  wrote:
> > > > And this too http://www.djangobook.com/en/2.0/
> > > > 
> > > > 
> > > > On Fri, Nov 25, 2011 at 7:41 AM, Timothy Makobu 
> > > >  
> > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > Please read this whole thing 
> > > > > https://docs.djangoproject.com/en/dev/howto/static-files/ 
> > > > > 
> > > > > 
> > > > > On Fri, Nov 25, 2011 at 6:28 AM, TANYA  > > > > (mailto:tani...@gmail.com)> wrote:
> > > > > > # Absolute filesystem path to the directory that will hold 
> > > > > > user-uploaded files.
> > > > > > # Example: "/home/media/media.lawrence.com/media/ 
> > > > > > (http://media.lawrence.com/media/)"
> > > > > > MEDIA_ROOT = ''
> > > > > > 
> > > > > > I want to upload css files and images so must I put them in 
> > > > > > /home/media or /home/my/media/path/ ? Should the filesystem path in 
> > > > > > settings.py be changed or should MEDIA_ROOT be left empty?
> > > > > > 
> > > > > > -- 
> > > > > > TANYA
> > > > > > -- 
> > > > > > 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%2bunsubscr...@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 
> > > > (mailto:django-users@googlegroups.com).
> > > > To unsubscribe from this group, send email to 
> > > > django-users+unsubscr...@googlegroups.com 
> > > > (mailto:django-users%2bunsubscr...@googlegroups.com).
> > > > For more options, visit this group at 
> > > > http://groups.google.com/group/django-users?hl=en.
> > > 
> > > 
> > > 
> > > -- 
> > > TANYA
> > > -- 
> > > 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%2bunsubscr...@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" 

Re: Caching at model class level

[Donald Stufft]

Normally this is cached using the Django caching framework, this lets you save 
it in memcache, redis, etc  


On Thursday, November 3, 2011 at 10:22 AM, Thomas Guettler wrote:

> Hi,
>  
> I try to reduce the number of db-queries in my app.
>  
> There is a model which changes almost never. It is like a "type of ticket"
> in a trouble ticket system.
>  
> On one page there are seven SQL-Queries (SELECT  FROM ticket_type where 
> id=123) which of course always return
> the same result.
>  
> I want to cache the objects:
>  
> t1=TicketType.objects.get(id=123)
> t2=TicketType.objects.get(id=123)
>  
> t1 and t2 should be the identical python object, not just objects containing 
> the same data.
>  
> Has someone done this before?
>  
> Here is my first version:
>  
> class ThreadLocalQueryset(models.query.QuerySet):
> _threadlocal=threading.local()
> _threadlocal.cache=dict() # The cache is at class-level. It survives a 
> request.
> def get(self, **kwargs):
> kwargs_tuple=tuple(kwargs.items())
> obj=self._threadlocal.cache.get(kwargs_tuple)
> if obj is not None:
> return obj
> obj=models.query.QuerySet.get(self, **kwargs)
> self._threadlocal.cache[kwargs_tuple]=obj
> return obj
>  
> class ThreadLocalManager(models.Manager):
> use_for_related_fields = True
> def get_query_set(self):
> return ThreadLocalQueryset(self.model, using=self._db)
>  
> class TicketType(models.Model):
> objects=ThreadLocalManager()
>  
> If there would be many TicketTypes, the interpreter would use more and more 
> memory, but there are few.
>  
> Feedback welcome,
> Thomas Güttler
>  
> --  
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>  
> --  
> 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: Long usernames in auth_user?

[Donald Stufft]

This is a known limitation and it's something that people _want_ to get fixed 
(but just merely increasing the length isn't helpful, because soon someone 
comes along with the new length + 1 and the same problem occurs). The issue is 
that the django.contrib.auth User model while providing a minimum (sort of) set 
of fields for a user, doesn't let you enhance it's internals very well. I think 
the core dev's are mostly waiting for someone to come up with a good solution 
to this problem. 

Now to answer your other question. 

There are 2 general ways of handling this, and neither one is perfect. One is 
to do as you did and modify the db to allow longer usernames, also being 
careful to modify anyplace that validates that the length is 30 so that it 
works across the sites.

The other method is to create your own auth handler (Pinax comes with one) that 
let's you authenticate against the email field on auth.User. Then in your 
signup process you save their email address to this field, and generate the 
username (I'm fond of UUID's for this). The final (optional) piece of this 
puzzle is to monkey patch User.__unicode__ to return self.email instead of 
self.username. 


On Wednesday, October 26, 2011 at 4:38 PM, Joakim Hove wrote:

> Hello,
> 
> I have been using a (in general quite popular I think ...) convention
> where the e-mail address has been used as username. I have solved this
> by asking the user for an e-mail address and a password, and then used
> the supplied e-mail address both as username and e-mail address when
> instantiating a User object. This has worked fine up until now.
> 
> Now suddenly someone came along with an e-mail address which was
> longer than the 30 characters limit imposed on the username; and
> things went to pieces. I have Googled this topic but did not find any
> clear cut simple solution, altough I am definitely not the first one
> to stumble over this problem.
> 
> So two questions:
> 
> 1) I modified the (development) database directly increasing the field
> size from 30 to 75; and that seemed to work nicely; but I am not very
> comfortable about the solution. What do you say?
> 
> 2) Any chance of changing this in a future release?
> 
> Joakim
> 
> -- 
> 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: Templates available to a cluster

[Donald Stufft]

If I wanted maximum performance from a distributed on the fly template system. 
I'd probably store them in a fast document db.

On Wednesday, October 19, 2011 at 5:54 PM, Kurtis Mullins wrote:

> Very true, I could definitely implement it as a pluggable loader. I'll try to 
> find the DB Template Loader too. I'm mainly concerned with this being a large 
> bottle neck for our front-facing pages so I'm not sure which path to choose. 
> Maybe some R is in order :) Thanks!
> 
> On Wed, Oct 19, 2011 at 5:52 PM, Donald Stufft <donald.stu...@gmail.com 
> (mailto:donald.stu...@gmail.com)> wrote:
> > The template system uses pluggable loaders that can locate a template based 
> > upon it's name. So using that you can store your template anywhere. There 
> > is already an app for storing templates in the db, you could easily make 
> > one to store it somewhere else as well. 
> > 
> > On Wednesday, October 19, 2011 at 5:48 PM, Kurtis wrote:
> > 
> > > I'm working on a project where I will eventually need to be able to
> > > add/delete/manage templates on the fly. Our Django Application Servers
> > > are setup as a cluster behind an Nginx Front-end Server.
> > > 
> > > We're not at that point, yet -- but I wanted to see if there's any
> > > architectural issues I need to prepare for. I was thinking we could
> > > store them on some sort of a networking file system but then I worry
> > > about load-times and stability. We could store them in a database but
> > > I imagine that may slow things down even more, plus we'd have to build
> > > some sort of a system for pulling templates from the database.
> > > 
> > > If anyone's attempted this sort of thing before, I'd be interested in
> > > hearing some options you took and the outcome.
> > > 
> > > 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 
> > > (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 
> > (mailto:django-users@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com 
> > (mailto:django-users%2bunsubscr...@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 
> (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: Templates available to a cluster

[Donald Stufft]

The template system uses pluggable loaders that can locate a template based 
upon it's name. So using that you can store your template anywhere. There is 
already an app for storing templates in the db, you could easily make one to 
store it somewhere else as well. 


On Wednesday, October 19, 2011 at 5:48 PM, Kurtis wrote:

> I'm working on a project where I will eventually need to be able to
> add/delete/manage templates on the fly. Our Django Application Servers
> are setup as a cluster behind an Nginx Front-end Server.
> 
> We're not at that point, yet -- but I wanted to see if there's any
> architectural issues I need to prepare for. I was thinking we could
> store them on some sort of a networking file system but then I worry
> about load-times and stability. We could store them in a database but
> I imagine that may slow things down even more, plus we'd have to build
> some sort of a system for pulling templates from the database.
> 
> If anyone's attempted this sort of thing before, I'd be interested in
> hearing some options you took and the outcome.
> 
> 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 
> (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: Getting into professional django development

[Donald Stufft]

+1 for Always Develop against a Release, and if you are forced to use a VCS 
checkout, at least use pip and pin your requirements to a specific point in the 
history for that VCS.

On Tuesday, October 18, 2011 at 11:00 AM, Tom Evans wrote:

> On Tue, Oct 18, 2011 at 3:47 PM, Paul Menzel  (mailto:pm.deb...@googlemail.com)> wrote:
> > Dear Dan,
> >  
> >  
> > [Reordering the message so that it is easier to see the connection.]
> >  
> > Am Dienstag, den 18.10.2011, 06:46 -0700 schrieb Dan Gentry:
> >  
> > > On Oct 18, 3:10 am, kenneth gonsalves  > > (http://thenilgiris.com)> wrote:
> > > > On Tue, 2011-10-18 at 12:36 +0530, kenneth gonsalves wrote:
> > > > > On Mon, 2011-10-17 at 23:45 -0700, Kevin wrote:
> > > > > > Currently I have been focusing on the following:
> > > > >  
> > > > >  
> > > >  
> > > >  
> > > > > > * Django 1.2
> > > >  
> > > > > 1.3 belongs to the stone age - since you are learning, it would be a
> > > > > good idea to work with the current svn trunk, updating every week or
> > > > > so.
> > > > > --
> > > > >  
> > > >  
> > > >  
> > > > s/1.2/1.3/
> >  
> > > With all due respect to Mr. Gonsalves, I do not care to work with the
> > > Django trunk unless I'm just playing around with something.  My goal
> > > is always to produce a production quality application.  Even the more
> > > stable than average Django trunk cannot provide the consistency needed
> > > to deliver an app to a customer.  Plus, I don't need the extra work of
> > > basing my code on a moving target.  When trunk becomes v1.4, I will
> > > convert my applications and upgrade.
> > >  
> >  
> >  
> > Please read the message you are referring to again. Kenneth corrected
> > the post [2] (although the `sed`-command should be `s/1.3/1.2/`. »The
> > latest official version is 1.3.1.« [1], so Kenneth suggested to use the
> > current stable release.
> >  
>  
>  
> I can't stand incorrect pedantry - this is my curse.
>  
> Kenneth actually said that "1.3 is ancient, you should be using
> trunk", which he corrected to "1.2 is ancient, you should be using
> trunk". His advice, regardless of which version you look at, is to use
> trunk - not the latest stable release.
>  
> I agree with Dan, you should always develop against a release -
> although I am also a dinosaur. The cool kids these days are happy to
> work against github projects, usually master, or randomly forked from
> master. It is beyond me how you are supposed to know what caused the
> breakage if you have no clue about what changes have been made.
>  
> A good part of my job relates to SCM, and once you have taught
> yourself the good practices of SCM, you can clearly see the downsides
> of not following them; this is one of them. Control change to manage
> risk.
>  
> 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: a django question about "python manage.py syncdb"

[Donald Stufft]

You need a __init__.py in your models.py. You also need to import all your 
models into that __init__.py.

If I recall you'll also want to set

class Meta:
app_label = "the name of your package"

Because the models directory will screw up Django's ability to auto figure it 
out.  


On Saturday, October 15, 2011 at 12:32 AM, Chen Xu wrote:

> I tried to delete models.py, and just have a /model subdirectory, but "pythin 
> manage.py syncdb" doesnt pick up the models in /models directory,
> Do i need to change some configurations to tell Django to use /models 
> subdirectory.
> Or do I need __init__.py in my /models subdirectory, I tried both, neither 
> works.
>  
>  
>  
> Thanks
>  
>  
>  
> On Fri, Oct 14, 2011 at 4:31 AM, Phang Mulianto  (mailto:braveh...@gmail.com)> wrote:
> > maybe you can try remove the models.py coz by default syncdb look for 
> > models.py or anything beneath models folder...but cannot do both of them... 
> >  
> > On Oct 14, 2011 5:49 PM, "Chen Xu"  > (mailto:xuche...@gmail.com)> wrote:
> > > and when i tried "python manage.py sqlall  "  it gives empty.
> > > I think is it because I am not importing  properly or something else is 
> > > going wrong.
> > >  
> > >  
> > > Thanks
> > >  
> > >  
> > >  
> > >  
> > >  
> > > On Fri, Oct 14, 2011 at 2:46 AM, Chen Xu  > > (mailto:xuche...@gmail.com)> wrote:
> > > > I know that will work, but what I can do to just make "python manage.py 
> > > > syncdb" work?
> > > >  
> > > > Thanks very much
> > > >  
> > > >  
> > > > On Fri, Oct 14, 2011 at 2:37 AM, nicolas HERSOG  > > > (mailto:n.her...@gmail.com)> wrote:
> > > > > You can also type python manage.py sqlall  and copy paste 
> > > > > sql instructions in your bd
> > > > >  
> > > > > On Fri, Oct 14, 2011 at 11:23 AM, Chen Xu  > > > > (mailto:xuche...@gmail.com)> wrote:
> > > > > > Hi,  
> > > > > > I am new to Django.
> > > > > > I have installed Django and go t everything set up correctly, just 
> > > > > > started some easy tutorials.
> > > > > >  
> > > > > > So when I do  
> > > > > > Django-admin.py startapp  blog
> > > > > >  
> > > > > >  
> > > > > > it creates a /blog directory that looks like thsi
> > > > > > /blog
> > > > > > - __init__.py
> > > > > > - tests.py
> > > > > > - models.py
> > > > > > - views.py
> > > > > >  
> > > > > > I know in Django, when you run "python manage.py syncdb", it will 
> > > > > > look through models.py, and create all the table it finds.
> > > > > > However, I dont want to create all my tables in models.py, becaue 
> > > > > > when my proj get bigger, it is hard to maintain.
> > > > > > Therefore, I create a subdirectory "/Models" to store all my model
> > > > > >  
> > > > > > /blog
> > > > > > - __init__.py
> > > > > > - tests.py
> > > > > > - models.py
> > > > > > - views.py
> > > > > > /Models
> > > > > > - __init__.py
> > > > > > post.py
> > > > > >  
> > > > > >  so in my   
> > > > > > models.py: (only 2 lines)
> > > > > > from django.db import models
> > > > > > from blog.Models import post
> > > > > >  
> > > > > > in my post.py: (only 3 lines)
> > > > > > from django.db import models
> > > > > > class post(models.Model):
> > > > > >   body = models.TextField()
> > > > > >  
> > > > > >  
> > > > > > and then when I run "python manage.py syncdb" , it doesn't create 
> > > > > > the table "post" for me.
> > > > > >  
> > > > > > Could anyone please help?
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > Thanks very much
> > > > > > Best regards
> > > > > >  
> > > > > >  
> > > > > > --  
> > > > > > ⚡ Chen Xu ⚡
> > > > > > --  
> > > > > > 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%2bunsubscr...@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 
> > > > > (mailto:django-users@googlegroups.com).
> > > > > To unsubscribe from this group, send email to 
> > > > > django-users+unsubscr...@googlegroups.com 
> > > > > (mailto:django-users%2bunsubscr...@googlegroups.com).
> > > > > For more options, visit this group at 
> > > > > http://groups.google.com/group/django-users?hl=en.
> > > >  
> > > >  
> > > >  
> > > > --  
> > > > ⚡ Chen Xu ⚡
> > >  
> > >  
> > >  
> > > --  
> > > ⚡ Chen Xu ⚡
> > > --  
> > > You 

Re: Second coming of Java?

[Donald Stufft]

+1 for what Tom said.

Django is perfectly capable at working at every level of the web. While it's 
true that once you start scaling at super high loads that you start having to 
do some lower level stuff to cope, the same is true of any application 
framework really.

If your shop prefers Java then by all means continue to use Java, but coming 
into the Django Users Mailing list and telling us that Java should be used for 
any "serious" web application and expecting anything but being told to go away, 
or that you are wrong is asking for pain.  


On Thursday, October 13, 2011 at 9:05 AM, Tom Evans wrote:

> On Thu, Oct 13, 2011 at 1:42 PM, Maksymus007  (mailto:maksymus...@gmail.com)> wrote:
> > What my and company I work for experience show is that Java should simply by
> > used to solve other problems that Django or RoR solves.
> > Developing medium-sized web-app in Django is for us big pain in the neck,
> > especially when compared to development of other app using
> > Java + PrimeFaces and all enterprise-stuff (Hibernate, ehCache etc).
> > I don't see Django with Python with their, lets say, community and
> > non-enterprise grade solutions (good WORKING SOAP library for Python?) is
> > not suitable for really big thinks, thats all.
> > On the other side..check Play! Framework for java ;)
> >  
>  
>  
> Only people who are brought up on Java EE/.NET believe SOAP is
> useful/good. The rest of the world (yes, even us Enterprise with a big
> E) prefer simpler REST interfaces.
>  
> BTW, it is ironic that you are arguing that python lacks enterprise
> features and give Hibernate as something Java has over Python on a
> Django mailing list. Hibernate is an ORM and object persistence
> library… which is precisely what Django's ORM does.
>  
> We implement real world enterprise solutions using Django, and love
> it. Take your FUD elsewhere please!
>  
> 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: Second coming of Java?

[Donald Stufft]

I think it's a load of tripe. There's plenty ways to speed up Python. And it's 
fast enough. It's not about being the fastest, but about being fast enough to 
get the job done, and having an enjoyable experience writing your web 
application.

Java is not that thing.  


On Wednesday, October 12, 2011 at 4:52 PM, ydjango wrote:

> What do you think?
>  
> http://www.cringely.com/2011/10/the-second-coming-of-java/
>  
> "When SSDs gain enough capacity there will be a shift from the Ruby
> world back to the Java world. Not for prototyping, because, well, it’s
> prototyping. But simply because the statement “Ruby is incredibly slow
> but I don’t care because my database is slower” will no longer be
> true. At that point Ruby (Python, Groovy, you name it) becomes the
> bottleneck." - from the above article
>  
> --  
> 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: Ajax replacement in django

[Donald Stufft]

 I don't think there's any reason to insult anyone, let's be civil. 


On Wednesday, October 12, 2011 at 10:50 AM, Chandrakant Kumar wrote:

> 
> You are another 'garbage' product of our country's shitty education system.
> 
> On 10/12/2011 08:09 PM, lankesh87 wrote:
> > Actually my project guide is asking me to search for ajax replacement
> > in django. So that way we dont have to use ajax.
> > 
> > I mean if we could only refrsh particular part in our web page without
> > refreshing the whole page "using django".
> > 
> > Thanx in advance and pardone me for my foolish questions as i am new
> > to django and web but i do have some basic knowledge on
> > how html functions.
> > 
> > On Oct 12, 7:24 pm, Javier Guerra Giraldez > (http://guerrag.com)> wrote:
> > > On Wed, Oct 12, 2011 at 9:17 AM, lankesh87 > > (http://gmail.com)> wrote:
> > > >  I am developing a web application where i need ajax like features.
> > > > But I don't want to use ajax, so my question is- "is there any way to
> > > > perform ajax like functions in django?"
> > > > 
> > > 
> > > that kind of specifications (ajax-like but no ajax) sound very weird
> > > to me. I find only two explanations:
> > > 
> > > A) you don't know how HTTP works
> > > 
> > > or
> > > 
> > > B) when you say 'ajax' you're in fact talking about a specific library
> > > that you don't want to use and not the generic javascript-driven
> > > requests.
> > > 
> > > if A, then please do learn about HTTP first. then you'll not only
> > > realize what you really need, but will also be in position to make
> > > your applications like you want.
> > > 
> > > if B, then please tell us what is it that you don't want.
> > > 
> > > --
> > > 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 
> (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: How REST Access ?

[Donald Stufft]

 TastyPie is also good and one that I prefer over Piston. 


On Monday, October 3, 2011 at 11:20 AM, Javier Guerra Giraldez wrote:

> On Fri, Sep 30, 2011 at 10:23 PM, bino oetomo  (mailto:b...@indoakses-online.com)> wrote:
> > Dear All.
> > 
> > Kindly please give me your enlightment to CRUD Django database using
> > HTTP-GET.
> 
> 
> first of all, REST is not CRUD. you'll get in a world of pain if you
> simply expose your database.
> 
> second, check Django-Piston. even if you don't end up using it, it's
> a good architecture to copy.
> 
> 
> 
> -- 
> 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 
> (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: Question about losing port number.

[Donald Stufft]

 I think you might be on the wrong mailing list… There's no PHP around these 
parts ;)  


On Monday, September 26, 2011 at 3:30 PM, Chen Xu wrote:

> I have a general question about PHP:
> So basically I have a link, and I want the href to be absolute., so I do 
> 'https://' . $_SERVER['HTTP_HOST'] . '/login' ; this gives me 
> https://127.0.0.1/login on my local; however, what i really want is 
> https://127.0.0.1:9090/login, it is missing ":9090".
>  
> Could anyone please help?
>  
> --  
> ⚡ Chen Xu ⚡
>  --  
>  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: Removing SECRET_KEY from settings.py

[Donald Stufft]

$ cat settings.py

….

try:  
 from local_settings import *
except ImportError:
 pass


$ cat local_settings.py

….
SECRET_KEY = "blah"


On Friday, September 16, 2011 at 8:54 PM, Tim Chase wrote:

> Just returning to some Django work after a time away, I  
> (re)started an old project in 1.3 and hit an early issue. I'd  
> like to keep my settings.py under revision-control that is  
> somewhat publicly accessible, but don't want my SECRET_KEY  
> exposed. The solution I've opted for is the following excerpt of  
> my settings.py on which I'm hoping for feedback:
>  
>  SECRET_FILE = "secret.txt"
>  if os.path.exists(SECRET_FILE):
>  SECRET_KEY = file(SECRET_FILE).read()
>  else:
>  from random import choice
>  SECRET_KEY = ''.join([
>  choice(
>  'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'
>  ) for i in range(50)])
>  f = file(SECRET_FILE, 'w')
>  f.write(SECRET_KEY)
>  f.close()
>  
> (key generation ripped directly from  
> core/management/commands/startproject.py )
>  
> As best I can tell, this should allow me to place secret.txt on  
> machines I control, while allowing others to freely download the  
> code and deploy on their end with minimal trouble.
>  
> Any input would be greatly appreciated,
>  
> -tkc
>  
>  
>  
> --  
> 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: When is a good time to use db_index? Rule of thumb?

[Donald Stufft]

To expand, a better answer is when you have profiled your application and have 
shown a bottleneck, and have tested it with an index on that column and seen an 
improvement. 

db_index isn't free, it incurs a penalty on writes so you need to be careful 
when using them. 


On Friday, September 16, 2011 at 12:08 AM, Micah Carrick wrote:

> As an oversimplification.. any time you will be looking up a record based on 
> a field, then you want an index on that (or those) fields. If you're finding 
> a row based on a slug, you want to index that slug field. 
> 
> A good tool is to use the Django debug toolbar. When you load a page you can 
> take a look at the SQL queries. You can then use the 'dbshell' management 
> command to open up your database shell. Then you can then add "EXPLAIN " 
> before the SELECT queries to see how it's finding your data. Do a google 
> search on your database indexes and you'll find all sorts of details. 
> On Thu, Sep 15, 2011 at 8:38 PM, Micky Hulse  (mailto:rgmi...@gmail.com)> wrote:
> >  Hello,
> > 
> >  I have been using this great category/tag model:
> > 
> > https://github.com/praekelt/django-category/blob/master/category/models.py
> > 
> >  ... and I noticed that the author added a db_index on the SlugField of
> >  the Category model.
> > 
> >  I hate to admit it, but I don't think I have ever explicitly used
> >  db_index parameter on any of my models.
> > 
> >  When's a good time to use db_index? Is there a general rule of thumb
> >  when coding Django models?
> > 
> >  Sorry if silly question.
> > 
> >  Thanks so much!
> > 
> >  Cheers,
> >  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 
> > (mailto:django-users@googlegroups.com).
> >  To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com 
> > (mailto:django-users%2bunsubscr...@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 
> (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: Class-based views or "Traditional" Views for Django 1.3?

[Donald Stufft]

 Agreed, and fwiw both you Kurtis, and anyone else can feel free to ping me 
directly in #django if they need help getting the hang of CBV's, if i'm around 
(which I am most the day typically) I'll be more then happy to help. 


On Wednesday, September 14, 2011 at 9:54 AM, Andre Terra wrote:

> OTOH, getting the hang of it can be hard with the current state of the docs 
> and given that they require a completely different mindset when coding views.
> 
> 
> Cheers,
> AT
> 
> On Wed, Sep 14, 2011 at 10:35 AM, Donald Stufft <donald.stu...@gmail.com 
> (mailto:donald.stu...@gmail.com)> wrote:
> >  Class Based Views let you override and subclass views to modify their 
> > behavior, I find them to be very quick once you get the hang of them. 
> > 
> > On Wednesday, September 14, 2011 at 9:33 AM, Kurtis wrote:
> > 
> > > Hey Guys,
> > > 
> > > I'm relatively new to Django 1.3. As others have noticed, there is
> > > less documentation around the Class-Based views than typical for
> > > Django. No needs for apologies as I have seen in other threads. I
> > >  don't blame others for my lack of knowledge :)
> > > 
> > > If I am working on a large project from scratch, would it be smart to
> > > just use the traditional, function/method-based views? Or should I go
> > > ahead and try to adapt the class-based views? I am working on a
> > >  deadline so the amount of time burnt searching more in-depth for my
> > > answers could be a problem. On the other hand, if there are any
> > > advantages to using Class-based views, I may want to take advantage of
> > > them. Unfortunately, I don't know enough about the Class-based views
> > >  to really weigh that out on my own. Any information regarding this
> > > decision would be greatly appreciated.
> > > 
> > > Thanks!
> > > -Kurtis Mullins
> > > 
> > > -- 
> > > 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 
> > (mailto:django-users@googlegroups.com).
> >  To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com 
> > (mailto:django-users%2bunsubscr...@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 
> (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: Class-based views or "Traditional" Views for Django 1.3?

[Donald Stufft]

 Class Based Views let you override and subclass views to modify their 
behavior, I find them to be very quick once you get the hang of them. 


On Wednesday, September 14, 2011 at 9:33 AM, Kurtis wrote:

> Hey Guys,
> 
> I'm relatively new to Django 1.3. As others have noticed, there is
> less documentation around the Class-Based views than typical for
> Django. No needs for apologies as I have seen in other threads. I
> don't blame others for my lack of knowledge :)
> 
> If I am working on a large project from scratch, would it be smart to
> just use the traditional, function/method-based views? Or should I go
> ahead and try to adapt the class-based views? I am working on a
> deadline so the amount of time burnt searching more in-depth for my
> answers could be a problem. On the other hand, if there are any
> advantages to using Class-based views, I may want to take advantage of
> them. Unfortunately, I don't know enough about the Class-based views
> to really weigh that out on my own. Any information regarding this
> decision would be greatly appreciated.
> 
> Thanks!
> -Kurtis Mullins
> 
> -- 
> 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: two independent Django sites, one user - share User objects

[Donald Stufft]

You could pick one site to be your canonical site, and add it as a second db to 
the first, and then use a custom authentication backend to auth against that 
site, then create a local user with the same password hash. 


On Monday, September 12, 2011 at 7:38 AM, Markus Gattol wrote:

> Say I have n (e.g. three) independent Django sites and one user. Rather than 
> having n times a password/username I'd like to share this across all n sites. 
> Also a users profile [0] and so forth. Now assume I don't want to use OpenID, 
> how would I be able to have User objects in sync across n Django sites? Maybe 
> using ZeroMQ and have each Django site listen to some actions on other Django 
> sites and then replay whatever action takes place on all Django sites?
> 
> 
> [0] 
> https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
>  
> 
>  -- 
>  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/-/8wLFTRFTbG4J.
>  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: Streamlining DJango Deployment — Novel idea from the world of CMSs

[Donald Stufft]

Cal,

He's not looking to automate the install for the Developer of a Django Project, 
but for the End Users of a Django Project.

So if I, or another developer wrote a WordPress clone using Django and then 
allow a third party to come and download my Wordpress clone and easily install 
it.  


On Thursday, September 8, 2011 at 7:52 AM, Cal Leeming [Simplicity Media Ltd] 
wrote:

> The subject of self contained deployments has already been *heavily* 
> discussed in other threads. Self contained / single binary deployments is 
> something that Roberto @ UNBIT is currently working on (and myself), and if 
> you do a search on the mailing list, you'll see tons of ideas on this 
> already. And believe me, it's not as simple as it may seem. (consider cross 
> OS libs, file system loaders etc).
>  
> Secondly, the OP said the following things are wrong:
>  
> - Doesn't cater to people who don't know Python  
> This is absolutely absurd, Django is a *python web framework*.
>  
> - Requires the installer to be a developer (pretty much)  
> Again, the developer would be the one 'creating' the project. If they didn't 
> understand the concepts behind how to make django talk to a webapp server, 
> then they need to learn. Simple.
>  
> Without being too rude, if you are looking to automate the install of a 
> framework, then you need to understand what the framework does. I am 
> completely against your proposed concept, because you are attempting to take 
> away the *need to understand* how things work.  
>  
> Cal
>  
>  
> On Thu, Sep 8, 2011 at 12:37 PM, Donald Stufft <donald.stu...@gmail.com 
> (mailto:donald.stu...@gmail.com)> wrote:
> > This is a hard question. It would probably be nice to offer a self 
> > contained deployment that nginx/apache could just proxy too, maybe pick 
> > that as the default, and then add in writing a fcgi or wsgi file for use 
> > with regular hosting.
> >  
> > On Thursday, September 8, 2011 at 7:34 AM, graeme wrote:
> >  
> > > He wants to be able to emulate the installation of a typical PHP CMS.
> > > This is often 1) get database username and poassword, 2) copyfiles to
> > > server, 3) navigate to an install URL, 4) fill in db username and
> > >  password and other config on a set of forms on web page.
> > >  
> > > Installing Django and the app you want to use is much more complex and
> > > forbidding requiring use of the command line and editing settings.py.
> > >  
> > > One question is what server configurations this will support.
> > >  mod_wsgi? fastcgi? others? Will this type of user be able to pick the
> > > right choice?
> > >  
> > > On Sep 8, 12:45 am, Calvin Spealman <ironfro...@gmail.com 
> > > (http://gmail.com)> wrote:
> > > > Can you explain to those of us to whom it is not obvious, what is the
> > > > point of this proposal? I don't understand what problem it would
> > > > solve.
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > On Wed, Sep 7, 2011 at 10:41 AM, Alec Taylor <alec.tayl...@gmail.com 
> > > > (http://gmail.com)> wrote:
> > > > > Good morning,
> > > >  
> > > > > I have just recently starting migrating over from WordPress and 
> > > > > Drupal to
> > > > > the world of DJango.
> > > >  
> > > > > First of all, let me say that yes, I am aware that DJango is not a 
> > > > > CMS!!!
> > > >  
> > > > > Now, onto my suggestions on how to streamline DJango deployment.
> > > > >  
> > > >  
> > > > > = What's wrong with the current method? =
> > > >  
> > > > > • Doesn't cater to people who don't know Python
> > > > > • Requires the installer to be a developer (pretty much)
> > > > >  
> > > >  
> > > > > I'm building a social-network catering to student-groups, 
> > > > > users-groups and
> > > > > game-clans. I will be releasing this under (probably) the New BSD 
> > > > > license.
> > > > > Because I want as many people as possible to be able to use this 
> > > > > project, I
> > > > >  want to make it very easy for non-developers to setup this 
> > > > > social-network on
> > > > > there servers.
> > > > > 
> > > >  
> > > > > = What are you suggesting? =
> > > >  
> > > > > A four-step install process.

Re: Streamlining DJango Deployment — Novel idea from the world of CMSs

[Donald Stufft]

This is a hard question. It would probably be nice to offer a self contained 
deployment that nginx/apache could just proxy too, maybe pick that as the 
default, and then add in writing a fcgi or wsgi file for use with regular 
hosting.

On Thursday, September 8, 2011 at 7:34 AM, graeme wrote:

> He wants to be able to emulate the installation of a typical PHP CMS.
> This is often 1) get database username and poassword, 2) copyfiles to
> server, 3) navigate to an install URL, 4) fill in db username and
> password and other config on a set of forms on web page.
>  
> Installing Django and the app you want to use is much more complex and
> forbidding requiring use of the command line and editing settings.py.
>  
> One question is what server configurations this will support.
> mod_wsgi? fastcgi? others? Will this type of user be able to pick the
> right choice?
>  
> On Sep 8, 12:45 am, Calvin Spealman  
> wrote:
> > Can you explain to those of us to whom it is not obvious, what is the
> > point of this proposal? I don't understand what problem it would
> > solve.
> >  
> >  
> >  
> >  
> >  
> > On Wed, Sep 7, 2011 at 10:41 AM, Alec Taylor  > (http://gmail.com)> wrote:
> > > Good morning,
> >  
> > > I have just recently starting migrating over from WordPress and Drupal to
> > > the world of DJango.
> >  
> > > First of all, let me say that yes, I am aware that DJango is not a CMS!!!
> >  
> > > Now, onto my suggestions on how to streamline DJango deployment.
> > > 
> >  
> > > = What's wrong with the current method? =
> >  
> > > • Doesn't cater to people who don't know Python
> > > • Requires the installer to be a developer (pretty much)
> > > 
> >  
> > > I'm building a social-network catering to student-groups, users-groups and
> > > game-clans. I will be releasing this under (probably) the New BSD license.
> > > Because I want as many people as possible to be able to use this project, 
> > > I
> > > want to make it very easy for non-developers to setup this social-network 
> > > on
> > > there servers.
> > > 
> >  
> > > = What are you suggesting? =
> >  
> > > A four-step install process.
> > > • Install pre-packaged Python+DJango-script package
> > > •http://i53.tinypic.com/2055fg8.png
> > > •http://i55.tinypic.com/e8lgtg.png
> > > •http://i55.tinypic.com/o0qiow.png
> > > •http://i55.tinypic.com/o0qiow.png
> > > 
> >  
> > > What are your thoughts on the DJango deployment redesign?
> >  
> > > Would anyone be interested in getting involved (making this happen!)?
> >  
> > > Best regards,
> >  
> > > Alec Taylor
> >  
> > > --
> > > 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/-/_b3bjdPN5_AJ.
> > > 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.
> >  
> > --
> > Read my blog! I depend on your acceptance of my opinion! I am 
> > interesting!http://techblog.ironfroggy.com/
> > Follow me if you're into that sort of 
> > thing:http://www.twitter.com/ironfroggy
>  
> --  
> 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: Streamlining DJango Deployment — Novel idea from the world of CMSs

[Donald Stufft]

 We talked a little on IRC, but just thought i'd reiterate my thoughts.  

This should not be in core, and I don't believe it ever has a chance of being 
in core.

That being said, I think that an external "installer" app like this wouldn't be 
the worst thing in the world, and could help to make an out out of the box 
Django Project (not django itself) an easier thing to distribute.

I think if you go forward with this you'll best serve yourself, and the 
community by not making it django specific, but instead make an easy way to 
create a self contained installer/runtime container for wsgi based projects and 
then someone who creates a project in Django (like say a wordpress like site, 
or a forum like site), and wants to prepackage it for the masses can then use 
your project to create an easy installer/deployment container to get started 
with the project.  


On Wednesday, September 7, 2011 at 10:41 AM, Alec Taylor wrote:

> Good morning,
>  
> I have just recently starting migrating over from WordPress and Drupal to the 
> world of DJango.
>  
> First of all, let me say that yes, I am aware that DJango is not a CMS!!!
>  
> Now, onto my suggestions on how to streamline DJango deployment.
> 
>  
> = What's wrong with the current method? =
>  
> • Doesn't cater to people who don't know Python
> • Requires the installer to be a developer (pretty much)
> 
>  
> I'm building a social-network catering to student-groups, users-groups and 
> game-clans. I will be releasing this under (probably) the New BSD license. 
> Because I want as many people as possible to be able to use this project, I 
> want to make it very easy for non-developers to setup this social-network on 
> there servers.
> 
>  
> = What are you suggesting? =
>  
> A four-step install process.
> • Install pre-packaged Python+DJango-script package
> • http://i53.tinypic.com/2055fg8.png
> • http://i55.tinypic.com/e8lgtg.png
> • http://i55.tinypic.com/o0qiow.png
> • http://i55.tinypic.com/o0qiow.png
> 
>  
> What are your thoughts on the DJango deployment redesign?
>  
> Would anyone be interested in getting involved (making this happen!)?
>  
> Best regards,
>  
> Alec Taylor
>  
>  --  
>  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/-/_b3bjdPN5_AJ.
>  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.