|
I'm at the point where I want to handle editing and deleting object models from the user side. I get how to create and read objects from the back-end, but is there a Django-ish way to edit and delete things from the front-end? Also, I'm deploying on Heroku, and I keep running into problems with the database. I use SQLite on my end, but Heroku needs PostgreSQL. I added the Heroku database and wsgi settings, and it works fine on Heroku, but running it locally with Foreman gives me this issue: code:
Plus, I thought Heroku was supposed to handle the migration from SQLite to PostgreSQL itself, so I shouldn't have to change settings myself?
|
# ? Feb 25, 2014 21:07 |
|
|
# ? May 31, 2024 12:11 |
MonkeyMaker posted:Wait, switching on DEBUG changed the way it acts? Yup, that appears to be the case, as strange as it may be. Unfortunately, I can't share the whole model and methods. Your question about the custom admin has got me thinking though - this one is an MPTT model, and that does custom admin stuff for rendering the hierarchy picklist options. I wonder if that's the culprit. Don't see any reference to the DEBUG setting in there, so doesn't really explain that behavior, but I'm gonna play around with it some more.
|
|
# ? Feb 25, 2014 22:27 |
Pollyanna posted:I'm at the point where I want to handle editing and deleting object models from the user side. I get how to create and read objects from the back-end, but is there a Django-ish way to edit and delete things from the front-end? Your CRUD operations (create, read, update, delete) always happen on the back-end. The only way for somebody to do it through the front should be via the back-end (). The Django way of doing this is through forms. It sounds like you may need two settings.py files, one that heroku will use, and one that you will use locally. My settings.py is all setup for the server to use, but at the bottom of it I have: code:
code:
I do not check in settings_local.py to source control or deploy it anywhere, it only needs to be used on my local machine. fletcher fucked around with this message at 22:44 on Feb 25, 2014 |
|
# ? Feb 25, 2014 22:34 |
|
fletcher posted:I do not check in settings_local.py to source control or deploy it anywhere, it only needs to be used on my local machine. If I may sing the praises of Two Scoops of Django for a moment, they have a very good section on why you should avoid the settings_local.py anti pattern. (the short version is: unchecked-in code means it can be lost, also means all team members will have different settings_local.py files which leads to "It doesn't do that for me" errors that take hours to debug.) Instead, have a settings folder in your project that contains all your different settings_*.py files (i.e. production, testing, development) and check them all in. To avoid checking in sensitive information like SECRET_KEY, leave it out of settings_production.py and instead pass it in via an environment variable on the server. In your settings_development.py you can have a throwaway SECRET_KEY variable that you do not use in production just to stop you having to faff around with it. This won't really affect you when you're working alone but it's a good habit to get into.
|
# ? Feb 25, 2014 22:58 |
|
Why does this happen, though? I tracked it down to calling dj_database_url.config(), which tries to configure a database by looking for an environmental variable in my system. Turns out that even though Heroku configured a DATABASE_URL for me, at least according to heroku config, $DATABASE_URL doesn't actually return anything:code:
|
# ? Feb 25, 2014 23:09 |
NtotheTC posted:If I may sing the praises of Two Scoops of Django for a moment, they have a very good section on why you should avoid the settings_local.py anti pattern. (the short version is: unchecked-in code means it can be lost, also means all team members will have different settings_local.py files which leads to "It doesn't do that for me" errors that take hours to debug.) This seems like a great idea, but I guess I should mention the other piece of my puzzle: Chef. I already have all my environments defined in Chef (prod, testing, dev, etc), and they all use the same settings_local.py.erb template file. So while my settings_local.py doesn't come from the same repo as my django app, it does come from a central repo and all devs would have the same copy of it. Not saying this is a great setup, but that's why the settings_local.py pattern appealed to me in the first place.
|
|
# ? Feb 25, 2014 23:14 |
|
Pollyanna posted:Why does this happen, though? I tracked it down to calling dj_database_url.config(), which tries to configure a database by looking for an environmental variable in my system. Turns out that even though Heroku configured a DATABASE_URL for me, at least according to heroku config, $DATABASE_URL doesn't actually return anything: Heroku configured DATABASE_URL on Heroku, not on your personal system. dj_database_url() also takes arguments for what to do when DATABASE_URL isn't found: code:
|
# ? Feb 25, 2014 23:26 |
|
MonkeyMaker posted:Heroku configured DATABASE_URL on Heroku, not on your personal system. Oh. That might explain it. But why not? Django is still gonna want to use $DATABASE_URL. And I tried the default argument by passing in the postgres string, but it didn't work at all for me.
|
# ? Feb 25, 2014 23:42 |
|
Pollyanna posted:Oh. That might explain it. But why not? Django is still gonna want to use $DATABASE_URL. Because Heroku You'll want to pass in a SQLite connection string and not a Postgres one since you're using SQLite locally and not Postgres.
|
# ? Feb 26, 2014 00:32 |
|
I'll do the whole "comment out while working locally" deal for now. I have some other bugs to fix... For example, I'm trying to save changes to an object like this: Python code:
|
# ? Feb 28, 2014 15:44 |
|
I'm assuming "ApplicationForm" is a modelform based on the Application model? If so, you don't need to do all this work of updating things on `app` and then saving it. Just do `form.save()` if form is valid. Django should handle converting the dates for you but if it doesn't you can always reset the date with strftime after you create a datetime object with strptime. Something like: code:
|
# ? Feb 28, 2014 19:28 |
|
I'm still confused as to why when I add an app the correct datetime format shows up, but when the app loads during editing it's in YYYY-MM-DD And now it gives me a "must be string, not datetime.date" error. Argh. I just bit the bullet and changed the datepicker around instead. Thanks for the help!
|
# ? Feb 28, 2014 22:35 |
|
I haven't done any Django work in months and I find I've forgotten half of everything. I've got a very simple model with two fields. The user shouldn't actually be typing in the data for those fields, my code will take what they submit, do stuff, and then create the data for those fields. I think what I would have done before I forgot half of everything is use a CreateView and ModelForm and override...form_valid, fields attribute to hide the model fields, and add my own fields. Am I remembering that right? In other news, I've been playing around with django-allauth for user registration and social network registration/login/auth/whatever. It seems to work very nicely, so I guess consider this if you need to do the whole login-with-your-facebook/google/github/whatever-account. In other, other news, I got my copy of Two Scoops of Django for Django 1.6 a couple days ago since I'm getting ready to do some Django work again. A lot of expanded content compared to the version for 1.5 as well as adding stuff specific for 1.6. In my opinion, worth buying even if you have the last version for 1.5. Unfortunately, they no longer have an ebook version... One thing they've changed their tune on is they no longer recommend using SQLite for local dev. I don't blame them and I've been using PostgreSQL locally since not long after I started doing any Django work. It's pretty simple to set up PostgreSQL no matter your OS. Thermopyle fucked around with this message at 21:30 on Mar 2, 2014 |
# ? Mar 2, 2014 21:23 |
|
Thermopyle posted:I haven't done any Django work in months and I find I've forgotten half of everything. Just mark the fields as uneditable with `editable=False`. This'll hide the fields from any model forms (and the admin). If, however, you need to be able to edit the fields in the admin, or in random forms, but not in all forms, then, yes, just hide the fields in the form's __init__ or fields tuple in class Meta. You shouldn't need to override form_valid. If you need the fields to be calculated when the form is saved, do that in the form's save(). Thermopyle posted:In other, other news, I got my copy of Two Scoops of Django for Django 1.6 a couple days ago since I'm getting ready to do some Django work again. A lot of expanded content compared to the version for 1.5 as well as adding stuff specific for 1.6. In my opinion, worth buying even if you have the last version for 1.5. Unfortunately, they no longer have an ebook version... Yeah, TSoD1.6 is a great update to 1.5. I completely understand why they didn't do an e-book, too. I know a lot of people are upset but people are always going to be upset so...gently caress 'em. Do what makes your life better. And, yes, don't use SQLite.
|
# ? Mar 2, 2014 22:08 |
|
Hello, I am having trouble trying to figure out how to test a set of multiple forms being submitted sequentially. I tried using FormWizard which works fine when I test manually in the browser, my session variables pass intact and I can move through multiple forms and do my transaction processing (ie. the FormWizard 'done' method launches and performs this work) But when I try to run it via the testing functions, I can POST multiple forms sequentially but they never seem to be on the same session or kick off the 'done' method. Is there something I am missing to testing multiple sequential form POST requests? test code (in this case the second step should be omitted via business logic in condition_dict: code:
|
# ? Mar 3, 2014 19:20 |
|
How do I change permissible symbols in a username using the default (contrib.auth) User model? Or should I allow my users to name themselves crap like +_+_+_+_+_+_+_+_+_+_+_+_+? edit: Also, I've been told to make sure that user input doesn't contain any malicious code. I was under the impression that Django checks this for me. Or should I employ a different strategy to take care of that? Pollyanna fucked around with this message at 21:50 on Mar 3, 2014 |
# ? Mar 3, 2014 21:36 |
|
Pollyanna posted:How do I change permissible symbols in a username using the default (contrib.auth) User model? Or should I allow my users to name themselves crap like +_+_+_+_+_+_+_+_+_+_+_+_+? Does it matter if they give themselves that ridiculous username? If not, don't worry about it. You can't change the default user but you could sub-class it and change the username's validator if you really need to. As for malicious input, Django protects against most of it.
|
# ? Mar 3, 2014 22:45 |
|
Nevermind my question above. I had some bad data in a form and figured out how to check for it in the tests. So far, I'm a big fan of FormWizard.
|
# ? Mar 4, 2014 02:28 |
|
Ahz posted:Nevermind my question above. I had some bad data in a form and figured out how to check for it in the tests. FormWizard is OK if you use it pretty straightforward. If you need to do anything tricky, though, it quickly turns to poo poo.
|
# ? Mar 4, 2014 18:44 |
|
MonkeyMaker posted:FormWizard is OK if you use it pretty straightforward. If you need to do anything tricky, though, it quickly turns to poo poo. I think I have it rigged up for most of my key business logic including dynamic fields, add/remove forms in the process, as well that messing around with preview and validation seems to work nicer than I expected. The built-in hooks seem to handle what I think I might need. But I'm curious what kinds of things you would consider tricky? I'm still open to new ideas as I develop.
|
# ? Mar 5, 2014 06:29 |
|
Anyone got some trip reports on doing Long Polling in Django? I'm making an offline web-app that syncs using a REST API, and I'd like to try it out. I don't necessarily need to though, I could just as easily have a rest API endpoint for changes and request periodically with a ?since parameter -- as it isn't mission critical to be real time -- but I'd like to explore long polling if its workable in Django.
|
# ? Mar 5, 2014 08:40 |
|
A few pages back I recall a discussion about not using local_settings files for sensitive settings you don't want exposed via source control. I've got an opportunity to rebuild my server (cause the image got wiped...) and currently I've got a basic shell script that runs through installing all the packages I require then uses sed to build a local settings file from a template. I'm working on making it into a collection of fabric tasks and I'm wondering if it's worth replacing the local_settings file with something else? I assume I can use fabric to define environment variables that will persist through reboot cycles (making/editing the root .bashrc?). Would that be preferable?
|
# ? Mar 11, 2014 10:11 |
|
Store your on-server production settings in environment variables. local_settings is fine for local development, as long as you add the file to .gitignore, so people can't steal your e-mail settings, etc.
|
# ? Mar 11, 2014 11:18 |
|
I have a vm I use for development that I try to keep as close to the production server as possible, so I'll set it all up to use settings in environment variables instead. It's mainly the database password and secret key that I want to keep secret anyway
|
# ? Mar 11, 2014 13:08 |
|
I'm trying to get Django going with uWSGI, but I run into this error:code:
|
# ? Mar 11, 2014 18:31 |
|
ufarn posted:Store your on-server production settings in environment variables. local_settings is fine for local development, as long as you add the file to .gitignore, so people can't steal your e-mail settings, etc. Two Scoops of Django disagrees. I'll type up their opinions on the matter when I get home.
|
# ? Mar 11, 2014 18:37 |
|
Thermopyle posted:Two Scoops of Django disagrees. I'll type up their opinions on the matter when I get home. Two Scoops does say to do your secret keys and passwords in environment variables, but ya, their configuration setup is pretty classy. I won't be home tonight but I'll try and get some notes tomorrow if no one beats me to it.
|
# ? Mar 11, 2014 19:11 |
Currently I'm running collectstatic on each server the app is deployed on, and django-pipeline handles the less & uglifyjs and all that stuff. It can be kinda time consuming though, I was thinking I should do collectstatic on just 1 server, package it up, and then deploy the packaged version. How should I go about doing that?
fletcher fucked around with this message at 19:29 on Mar 11, 2014 |
|
# ? Mar 11, 2014 19:16 |
|
ManoliIsFat posted:Two Scoops does say to do your secret keys and passwords in environment variables, but ya, their configuration setup is pretty classy. I won't be home tonight but I'll try and get some notes tomorrow if no one beats me to it. Yeah, I meant that Two Scoops says to not use a local settings file that you put in .gitignore. Chapter 5 starts out with this list of best practices:
Section 5.1 is called Avoid Non-Versioned Local Settings. quote:We used to advocate the non-versioned local_settings anti-pattern. Now we know better Their reasons:
They recommend a settings structure based upon a talk by Jacob Kaplan-Moss which looks like: code:
When you call manage.py commands you do it like: python manage.py shell --settings=twoscoops.settings.local Or you can set the DJANGO_SETTINGS_MODULE environment variable. (Personally, I set this variable in my virtualenv postactivate script.) Configuration like SECRET_KEY, AWS keys, and API keys goes in environment variables. Their reasons for this advice:
They have a lot more advice on the subject, but you should just go buy the drat book.
|
# ? Mar 11, 2014 19:38 |
|
Is there any way to get an electronic version of that book? They apparently don't have any Australian distributors for print copies so I'd be waiting weeks for a copy to ship unless I wanted to pay triple the price of the book alone on shipping (instead of just double).
|
# ? Mar 12, 2014 02:29 |
|
Ephphatha posted:Is there any way to get an electronic version of that book? They apparently don't have any Australian distributors for print copies so I'd be waiting weeks for a copy to ship unless I wanted to pay triple the price of the book alone on shipping (instead of just double). http://twoscoopspress.com/pages/two-scoops-of-django-1-6-faq#format-1.6
|
# ? Mar 12, 2014 04:19 |
|
Ephphatha posted:Is there any way to get an electronic version of that book? They apparently don't have any Australian distributors for print copies so I'd be waiting weeks for a copy to ship unless I wanted to pay triple the price of the book alone on shipping (instead of just double). Contact them. They're really good about helping people get copies of the book at affordable price if they can.
|
# ? Mar 12, 2014 15:03 |
|
At work, I do a compromise. I aim for the strict "12-factor"-ness of keeping settings out of VCS, but the fabric script will recommended settings based on the environment or what is already there. I think I prefer this style largely because I don't like attempting to version code with environments. That said, our fabric and puppet settings are generally kept in a separate repository from the app code.
|
# ? Mar 13, 2014 02:50 |
|
This is an odd gap in my knowledge I'm sure, but I've never built any Django sites that do much of anything with user authentication and authorization. I realize this is odd, as probably the vast majority of Django sites do, but anyway... Say you have a model PizzaRecipe. Users can input their own pizza recipes. What's the Django way of limiting users to viewing and deleting only recipes they create? I can, of course, add a user field to the PizzaRecipe model, add the currently-logged-in user to the model on save and then override get_queryset or whatever in my views to make sure the authenticated user matches the user field, but...it I feel like I'm overlooking something obvious since this seems like a basic thing that Django would have some pre-packaged way of handling. Thermopyle fucked around with this message at 22:48 on Mar 13, 2014 |
# ? Mar 13, 2014 22:38 |
|
Thermopyle posted:This is an odd gap in my knowledge I'm sure, but I've never built any Django sites that do much of anything with user authentication and authorization. I realize this is odd, as probably the vast majority of Django sites do, but anyway... Nope, that's the way to do it. Ideally you make a mixin that limits the queryset automatically. You could sort of achieve this with UserPassesTestMixin from django-braces, where the test is that the request.user matches self.get_object().user. They'll get a 404 if they try to view a Pizza they don't own. You'll still have to limit the ListView's queryset to just their Pizzas, though. EDIT: Or make a custom QuerySet/ModelManager that has a for_user(user) method that limits the queryset automatically for the user that's passed in, an example.
|
# ? Mar 14, 2014 13:41 |
|
I did something like this for my app, sorta:Python code:
Incidentally, for restricting parts of the site to people who are logged in, you can use the @login_required decorator from django.contrib.auth.decorators. Python code:
|
# ? Mar 15, 2014 07:39 |
|
MonkeyMaker posted:Nope, that's the way to do it. Thats fine for viewing recipes, but for deleting, one way to go would be to put a validator on the form for the recipe id (to delete) matches a corresponding user recipe. Otherwise you could be spoofed into having a user delete any recipe they want regardless of whether they can view it.
|
# ? Mar 15, 2014 13:41 |
|
Pollyanna posted:I did something like this for my app, sorta: Just be aware it doesn't check if the user is active (in case you ever plan to deactivate users)
|
# ? Mar 15, 2014 13:43 |
|
Ahz posted:Thats fine for viewing recipes, but for deleting, one way to go would be to put a validator on the form for the recipe id (to delete) matches a corresponding user recipe. Otherwise you could be spoofed into having a user delete any recipe they want regardless of whether they can view it. Your delete view should have a restricted queryset from which the item to be deleted is selected from. Again, the custom QuerySet or ModelManager will handle this for you, preventing you from doing more work than you have to or the same work more than once.
|
# ? Mar 15, 2014 18:43 |
|
|
# ? May 31, 2024 12:11 |
|
MonkeyMaker posted:Your delete view should have a restricted queryset from which the item to be deleted is selected from. Again, the custom QuerySet or ModelManager will handle this for you, preventing you from doing more work than you have to or the same work more than once. Yeah, this is what I did with a QuerySet, via the OwnershipMixin I wrote to handle all of this. Now I just slap the mixin on my views and all of this is taken care of.
|
# ? Mar 16, 2014 00:35 |