|
bitprophet, I bought your Django book >_< it better not suck
|
#
?
Mar 12, 2009 20:17
|
|
|
|
| # ? May 15, 2024 12:16 |
|
|
m0nk3yz posted:bitprophet, I bought your Django book >_< it better not suck Sorry...it does  it's actually just 376 pages of bad slash fanfiction starring Django Reinhardt and his pet snake.(Not really. It's not The Best Book Ever, there's a lot of things I wish we'd had time to do differently or go into more detail on, but I think we did a relatively good job with it given there were 3 authors without a lot of time on our hands.)
|
|
#
?
Mar 12, 2009 20:41
|
|
|
bitprophet posted:Sorry...it does Somehow I imagine m0nk3yz jumping straight up to Marty's book within a week.
|
|
#
?
Mar 13, 2009 00:27
|
|
|
king_kilr posted:Somehow I imagine m0nk3yz jumping straight up to Marty's book within a week. I like fiction!
|
|
#
?
Mar 13, 2009 02:07
|
|
|
Also, if anyone knows anyone, I'm looking for a senior-or-higher level web person, preferably someone with Django experience. (in MA)
m0nk3yz fucked around with this message at 02:59 on Mar 13, 2009 |
|
#
?
Mar 13, 2009 02:26
|
|
|
m0nk3yz posted:Also, if anyone knows anyone, I'm looking for a senior-or-higher level web person, preferably someone with Django experience. (in MA) You could try luring Doug Napoleone away from his job, I don't think he gets to do Python by day 
|
|
#
?
Mar 13, 2009 03:41
|
|
|
king_kilr posted:Somehow I imagine m0nk3yz jumping straight up to Marty's book within a week. Yea, probably. Ours is aimed more at beginner/intermediate folks coming from PHP. Still a decent overview, though. But hey, he already bought it, so that's another $0.90 for me...
|
|
#
?
Mar 13, 2009 04:11
|
|
|
bitprophet posted:Yea, probably. Ours is aimed more at beginner/intermediate folks coming from PHP. Still a decent overview, though. I have Marty's book, James' book, the "main" book, and bitprophet's book. I'm reading them all relatively simultaneously. It's been awhile since I've needed to do any large amount of web-programming, so I am trying to absorb as much as possible. Also, I hate HTML
|
|
#
?
Mar 13, 2009 13:54
|
|
|
Google just open-sourced its jaiku engine which it uses to power its twitter knockoff, jaiku. And its all django! http://code.google.com/p/jaikuengine/ Rock with the pros. This is really simple nice code. edit: Actually on further reading, its kinda wierd code, I guess thats cos its a django/app-engine app that I *think* was a twisted web app at one point. Not sure, but its got that smell about it. duck monster fucked around with this message at 15:10 on Mar 16, 2009 |
|
#
?
Mar 16, 2009 15:05
|
|
|
Is there an easy way to specify a textbox size when I'm using TabularInline in the admin interface? I want to use size='x' with certain text inputs generated from CharFields because the default size causes the table to get too wide.
|
|
#
?
Mar 18, 2009 02:00
|
|
|
king_kilr posted:Somehow I imagine m0nk3yz jumping straight up to Marty's book within a week. I picked up Marty's book and I really really like his explanations of django's metaclass voodoo. It never really clicked until I read the chapters explaining it. I mean I sort of got it but it wasn't all there. That alone made it worth the price of admission. Speaking of metaclass voodoo, now that I actually understand it 100% I am gonna try replacing django's sessions with a redis backend. Should aleviate the DB hammering when using sessions (this is inspired by Cal Henderson's rant about hitting the DB for a session on almost every view). As an aside, redis is sex. deimos fucked around with this message at 03:10 on Mar 18, 2009 |
|
#
?
Mar 18, 2009 03:05
|
|
|
I'm working on a medium-sized webapp (for school), and after some discussion we settled on Django as the framework. So far, we love it to bits, but I have some questions/requests for advice on the data model. Basically, the model is a set of RequestForms. A RequestForm is a bunch of text, integer, and boolean fields; a list of Sponsors (where a Sponsor is a (string, date, date, number, number) tuple); a list of Protocols (where a Protocol is a (string, number) tuple); and a few PurposeLists (basically maps (string => boolean)). The way I'm currently handling this is that each of these is its own model; Sponsor, Protocol, and PurposeList are each a Model in their own right, with a ForeignKey dependency on RequestForm. The view uses this to retrieve them, splices them into the RequestForm object, and proceeds from there. So: - can I move this into RequestForm's __init__() and save() methods, so that it happens automatically when a RF is created from the database/saved to the database and the view doesn't have to worry about it at all, just asking for (say) form.sponsors? - is this a reasonable design, or am I doing things completely wrong and Django actually has some built in feature to handle things like dictionaries automatically? I also have a question about mod_python, in case anyone here can answer this: is there a way to turn off cacheing or flush the cache, assuming I don't have root (and thus can't restart apache, which seems to be the 'official' way to do this)? The Django test server is a godsend, because whenever we test it on the deployment server, it's pretty much guaranteed to cache an incomplete or nonworking version of the site and then we have to wait for the cache to expire.
|
|
#
?
Mar 18, 2009 04:06
|
|
|
ToxicFrog posted:I also have a question about mod_python, in case anyone here can answer this: is there a way to turn off cacheing or flush the cache, assuming I don't have root (and thus can't restart apache, which seems to be the 'official' way to do this)? The Django test server is a godsend, because whenever we test it on the deployment server, it's pretty much guaranteed to cache an incomplete or nonworking version of the site and then we have to wait for the cache to expire. The quick answer: PythonAutoReload On may or may not work. The correct answer: don't use mod_python, use mod_wsgi. ToxicFrog posted:The way I'm currently handling this is that each of these is its own model; Sponsor, Protocol, and PurposeList are each a Model in their own right, with a ForeignKey dependency on RequestForm. The view uses this to retrieve them, splices them into the RequestForm object, and proceeds from there. I am really not understanding your models, maybe because you keep calling them things that generally conflict with what models are. A model is a model and there should not be List or Form in their classnames IMHO. A Sponsor model is a representation of a sponsor and a Purpose and not a PurposeList should be a representation of a purpose. That having been said, django does provide you with ModelForms which do all the form dirty work for you. Might want to start there. deimos fucked around with this message at 05:04 on Mar 18, 2009 |
|
#
?
Mar 18, 2009 04:57
|
|
|
ModelForms is not what I'm looking for; rereading the post, I named things poorly. "ResearchForm" should be "ResearchFundingApplication" or similar; it stores the information that on paper would be entered on an OR-5 form - researcher, project name, purpose of research, amount of funding requested, and so forth. This information is created via web form and eventually used to generate approval requests for dispatch to the Dean and whatnot. An application lists zero or more existing sponsors for that project, each one having a name, start and end date, funding amount and unique identifying number - that's the Sponsor class. It also must comply with zero or more specific protocols, each one of which is just a name and an approval number doled out by administration - that's the Protocol class. Finally, the PurposeList really is just a list of strings - on paper this is a section that reads "what is the purpose of this research project (check all that apply) [ ] money [ ] fame [ ] power [ ] other: _______________". On the python side I'm actually not sure whether to represent this as a list of strings or a set of strings; on the DB side it seems to make most sense (since I can't create columns on the fly!) to just store it as a comma-seperated list of strings or similar. I end up storing a list /somewhere/ either way - either I have a database of purpose-sets tied to applications, or I have a database of individual purposes (each one of which consisting of a single string) and the application has a list of FKs into that database - at which point I might as well make the purpose titles themselves the keys, since that's all they consist of and two purposes with the same title are by definition the same one, and we're right back where we started. None of this is really germane to the questions, though: does Django have a facility to store this kind of nested structure (eg, is there a StringListField, or can I create a list of TextFields and have it Just Work - experimentation and docs seem to indicate no to both, but I figure it's worth asking); and if not, is it safe/useful/advisable to put code in ResearchFundingApplication.__init__() and .save() to automatically translate that data in and out of the database, rather than doing it in the view? ToxicFrog fucked around with this message at 06:06 on Mar 18, 2009 |
|
#
?
Mar 18, 2009 06:04
|
|
|
Wow, I love Django already. Never programmed in Python before, but was able to setup a linux VM and blow through the OP in under two hours. There are a few changes besides __unicode__ in 1.0 but they weren't a big deal.
|
|
#
?
Mar 20, 2009 17:35
|
|
|
Ansible posted:Wow, I love Django already. Never programmed in Python before, but was able to setup a linux VM and blow through the OP in under two hours. There are a few changes besides __unicode__ in 1.0 but they weren't a big deal. Be sure to read the official docs/tutorial, they really are great (I feel like I say this alot).
|
|
#
?
Mar 20, 2009 22:19
|
|
|
Ansible posted:Wow, I love Django already. Never programmed in Python before, but was able to setup a linux VM and blow through the OP in under two hours. There are a few changes besides __unicode__ in 1.0 but they weren't a big deal. I'm glad the tutorial still works. I'm working on the itch to rewrite it all from scratch and I just might start a 'stupid-simple' for beginners Django blog as a motivation to do a whole rewrite. There's a bunch of little things in the tutorial that need refreshing since .96 -> 1 __str__ -> __unicode__ is an obvious one template.render(context) instead of render_to_response Not including all the all powerful context_processors which rock and are mandatory for any real app Aggregate is a sweet feature And just an all around refresh with better coding standards This might be my April project
|
|
#
?
Mar 21, 2009 00:46
|
|
|
ATLbeer posted:There's a bunch of little things in the tutorial that need refreshing since .96 -> 1 Wait, what? I am a django newb and for my first app I've been using render_to_response() b/c that's what the tutorial does. I'll go back to the docs again (I've been spending a LOT of time with the django docs over the past couple weeks) and look for that stuff, but can you give me the 30 second elevator pitch on why I should use template.render(context) and what are context_processors?? Thanks
|
|
#
?
Mar 21, 2009 02:06
|
|
|
Lamacq posted:Wait, what? I am a django newb and for my first app I've been using render_to_response() b/c that's what the tutorial does. I'll go back to the docs again (I've been spending a LOT of time with the django docs over the past couple weeks) and look for that stuff, but can you give me the 30 second elevator pitch on why I should use template.render(context) and what are context_processors?? You're fine using render_to_response I think he meant it in the reverse. context processors are basically a way to have a "global" template variable. So say you want a logic form on every page you could put it in a template context processor so every single view didn't have to provide it.
|
|
#
?
Mar 21, 2009 02:14
|
|
|
code:They are incredibly useful.
|
|
#
?
Mar 21, 2009 02:37
|
|
|
Sharktopus posted:
And I could have sworn there was some sort of RequestContext middleware that either shipped with Django at some point or was on their code.djangoproject.com wiki somewhere that did this for every response automatically but I'll be damned if I can't find it. I don't want to reimplement it half-assed if it's already out there, but I can.
|
|
#
?
Mar 21, 2009 04:09
|
|
|
No Safe Word posted:And I could have sworn there was some sort of RequestContext middleware that either shipped with Django at some point or was on their code.djangoproject.com wiki somewhere that did this for every response automatically but I'll be damned if I can't find it. I don't want to reimplement it half-assed if it's already out there, but I can. Are you takling about this: http://www.djangosnippets.org/snippets/3/
|
|
#
?
Mar 21, 2009 04:19
|
|
|
I've been searching around for something of use or inspiration, and I'm drawing blanks. I've made a couple small apps in Django already, and I'd like to make a relatively complex Eurogame-style board game with Django as the backend. Namely, I'd need to store hands of cards, status of board (location of guys, resources, etc.) and things like that. However, I'm not really sure how to go about it. Has anybody heard of, thought of or seen anything similar, or have any thoughts? The plan is to do an in-browser UI, and use Django to store the game state and do any needed computation, using some kind of serialization going between the two. The part I'm having trouble with is how to represent a game using Django in a sensible manner. pokeyman fucked around with this message at 06:10 on Mar 21, 2009 |
|
#
?
Mar 21, 2009 06:07
|
|
|
Django is just python, and python done right is allll about objects. Start off with a pen and paper, get all your objects (Think laterally! Player. Game board. Card. So on, all those things are objects.) Draw lines and poo poo between them describing how they interact. Now turn those objects into bunches of fields and poo poo and figure out how to turn those lines into relations (many-many one-one so on) and methods. Then turn that into a model.py file and turn your views.py file into a big firetruck to drive the models around and poo poo out html using them. Its all about objects. Modern software design always should be.
|
|
#
?
Mar 21, 2009 09:29
|
|
|
king_kilr posted:You're fine using render_to_response I think he meant it in the reverse. context processors are basically a way to have a "global" template variable. So say you want a logic form on every page you could put it in a template context processor so every single view didn't have to provide it. Yep... i inverted it... The shortcut of remder to response is the best practice
|
|
#
?
Mar 21, 2009 17:46
|
|
|
ATLbeer posted:Yep... i inverted it... The shortcut of remder to response is the best practice There was a few other differences as well, such as the new admin.py, maxlength renamed to max_length and prepopulated fields being defined in admin.py
|
|
#
?
Mar 21, 2009 21:10
|
|
|
Ansible posted:There was a few other differences as well, such as the new admin.py, maxlength renamed to max_length and prepopulated fields being defined in admin.py I believe we have a full listing here: http://docs.djangoproject.com/en/dev/releases/1.0/
|
|
#
?
Mar 21, 2009 22:13
|
|
|
duck monster posted:Then turn that into a model.py file and turn your views.py file into a big firetruck to drive the models around and poo poo out html using them. This is a fabulous mental picture. Thanks.
|
|
#
?
Mar 21, 2009 22:21
|
|
|
king_kilr posted:I believe we have a full listing here: http://docs.djangoproject.com/en/dev/releases/1.0/ Yup that is what I used. Started playing with Forms this weekend, I love it. For my overly ambitious webapp I am going to want an interface similar to mint.com's Transaction view, where it lists a series of items associated with the user and they can edit their attributes inline. Would django+AJAX be a workable way to do this or should I use another frontend? I say AJAX because I would prefer that the page doesn't reload when an edit is submitted or I could use straight django.
|
|
#
?
Mar 23, 2009 22:39
|
|
|
Ansible posted:Yup that is what I used. Yep, and if it's editing multiple models of the same type there take a look at formsets.
|
|
#
?
Mar 24, 2009 00:55
|
|
|
Does anyone find the django ORM to be slow? I have some pages with minimal ORM usage taking about 30ms, and others that are loading 30 or so models taking 150ms, but the queries only take about 10ms total. This is on the dev server, with mysql running on the same machine.
|
|
#
?
Mar 24, 2009 01:36
|
|
|
Mashi posted:Does anyone find the django ORM to be slow? I have some pages with minimal ORM usage taking about 30ms, and others that are loading 30 or so models taking 150ms, but the queries only take about 10ms total. This is on the dev server, with mysql running on the same machine. Try the Django Debug Toolbar to see if it's like a middleware or something else that is slowing stuff down.
|
|
#
?
Mar 24, 2009 01:49
|
|
|
No Safe Word posted:Try the Django Debug Toolbar to see if it's like a middleware or something else that is slowing stuff down. That's where I'm getting the readings from. I don't think its middleware because the same middleware is always run but the page load time can very between 30ms and 160ms. I'm also noticing that the slower pages show many more "context switches". Something to do with threads I think, though my app is single threaded. Mashi fucked around with this message at 03:14 on Mar 24, 2009 |
|
#
?
Mar 24, 2009 03:06
|
|
|
q/e
|
|
#
?
Mar 24, 2009 03:08
|
|
|
Mashi posted:That's where I'm getting the readings from. I don't think its middleware because the same middleware is always run but the page load time can very between 30ms and 160ms. I'm also noticing that the slower pages show many more "context switches". Something to do with threads I think, though my app is single threaded. Something isn't right. Can you post one of your slow views? Your using the development server currently? MySQL is installed locally? What OS?
|
|
#
?
Mar 24, 2009 04:08
|
|
|
Keep in mind the relational stuff does, as far as I'm aware, the joins at the python side rather than the mysql side. Is there a way to use views as a back-end to a model to force the joins to operate smoothly at the mysql side
|
|
#
?
Mar 24, 2009 07:56
|
|
|
duck monster posted:Keep in mind the relational stuff does, as far as I'm aware, the joins at the python side rather than the mysql side. Django's ORM can/does do SQL joins. It can't predict when you want related models, but if you use select_related it can join to pull out related models for you. As for using views as a back-end to a model... I'm not sure what you mean, but it don't sound right!
|
|
#
?
Mar 24, 2009 13:10
|
|
|
duck monster posted:Keep in mind the relational stuff does, as far as I'm aware, the joins at the python side rather than the mysql side. What? There's just no basis for what you just said. Django preforms normal SQL queries with joins. If you want to use views you can use the new managed option on models.
|
|
#
?
Mar 24, 2009 13:11
|
|
|
Mashi posted:As for using views as a back-end to a model... I'm not sure what you mean, but it don't sound right! I think he means SQL views which are quite distinct from Django views Would pile on the duck monster but hopefully he's already gotten the point!
|
|
#
?
Mar 24, 2009 14:23
|
|
|
|
| # ? May 15, 2024 12:16 |
|
|
bitprophet posted:I think he means SQL views which are quite distinct from Django views Hmm.. I'd LOVE to be able to do this. In fact, it seems to make perfect sense to be able to make read only models that could use more complex queries in the backend while being more lightweight in Python, since alot of what I'm doing is trying to squeeze out flexibility from the Django ORM, which is going to load alot of objects for each model that I don't need if I'm only displaying data.
|
|
#
?
Mar 24, 2009 14:49
|
|