Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »

king_kilr: May 25, 2007

Yes, someone could attack you by uploading a huge image(it will get read into memory), check out ticket #2070.

# ? Jun 2, 2008 19:57

Adbot: ADBOT LOVES YOU

# ? May 4, 2024 21:07

ashgromnies: Jun 19, 2004

I'm having trouble tying my image to a model. Actually I don't even need a model for it quite yet because it's fine for me to discard the image after I am done with it, but I'd still like to be able to keep track of what goes on.

I'm following the examples at http://www.djangoproject.com/documentation/models/model_forms/

code:

from django.db import models
from django import newforms as forms
import Image, ImageFile
from django.newforms.models import ModelForm


class ImageSizeLimitedField(forms.ImageField):
    def clean(self, value, initial):
        if not value:
            raise forms.ValidationError('Please upload an image')
        size = len(value['content'])
        if size > 1024000:
            raise forms.ValidationError('Filesize too large. Expected <= 1 megabyte')
        try:
            p = ImageFile.Parser()
            p.feed((value['content']))
            im = p.close()
        except IOError:
            raise forms.ValidationError('Please upload a valid image')
        return value

class ImageUploadForm(models.Model):
    #image = forms.ImageField(upload_to="/some/path")
    image = ImageSizeLimitedField(help_text='Image to upload', upload_to="uploads/%Y%m%d%M")

class ImageUploadForm(ModelForm):
    class Meta:
        model = ImageUpload

Then when I try to print an instance of my form in a template, it doesn't work.

code:

views.py:

def index(request):
    contextDict = {}
    form = ImageUploadForm()
    contextDict['UploadForm'] = form
    c = Context(contextDict)
    t = loader.get_template('colors/index.html')
    return HttpResponse(t.render(c))

code:

index.html:

{% extends "colors/base.html" %}
{% block content %}
{% load tags %}
<div id="main_content">
    {% for error in errors %}
    {{ error }}
    {% endfor %}
    <form enctype="multipart/form-data" method="post" action="/upload/">
        {{ UploadForm }}
        <input type="submit" value="coloriffic"/>
    </form>
</div>
{% endblock %}

However, my form works properly when I use the example I posted on the last page - it just doesn't get saved to the local filesystem.

# ? Jun 2, 2008 20:50

Wulfeh: Dec 1, 2005; The mmo worth playing: DAoC

http://www.djangoproject.com/documentation/db-api/#save-foo-file-filename-raw-contents

Have you tried that out? save_FOO_file()

# ? Jun 3, 2008 08:39

ashgromnies: Jun 19, 2004

Wulfeh posted:

http://www.djangoproject.com/documentation/db-api/#save-foo-file-filename-raw-contents

Have you tried that out? save_FOO_file()

Yeah but it doesn't give me a model to store in the database if I use that. I could write raw SQL to do it but I want to do it "the Django way".

I don't need the model right now but in the future I will because I'm going to do spidering/aggregating so it'd be nice to have the framework set up to support storing a record of each image in the database along with some metadata I calculate.

# ? Jun 3, 2008 14:59

king_kilr: May 25, 2007

You are putting a form field on a model.

# ? Jun 3, 2008 18:22

ashgromnies: Jun 19, 2004

king_kilr posted:

You are putting a form field on a model.

:facepalm: (waitaminute where'd the emoticon list in the forum rules go)

I feel dumb now. Thanks.

# ? Jun 3, 2008 19:36

Sock on a Fish: Jul 17, 2004; What if that thing I said?

Say I want to weigh the items returned in a search based on what other users have selected for the same search. Should I create a new model and new record for every search? Should I add a dict to the model on the items being searched? Is there an easy way to serialize a dict and put it in the database?

It seems like storing a record of every search made would eventually take up huge amounts of space, but at the same time it seems almost inappropriate to store this data in the model for the items being searched.

# ? Jun 3, 2008 21:49

Wulfeh: Dec 1, 2005; The mmo worth playing: DAoC

Sock on a Fish posted:

Say I want to weigh the items returned in a search based on what other users have selected for the same search. Should I create a new model and new record for every search? Should I add a dict to the model on the items being searched? Is there an easy way to serialize a dict and put it in the database?

It seems like storing a record of every search made would eventually take up huge amounts of space, but at the same time it seems almost inappropriate to store this data in the model for the items being searched.

Can you explain this a little more? You mean like tags? Everytime a keyword is searched, add that keyword to the table if its not found, otherwise add the count for that keyword + 1. Something like that?

ashgromnies posted:

Yeah but it doesn't give me a model to store in the database if I use that. I could write raw SQL to do it but I want to do it "the Django way".

I don't need the model right now but in the future I will because I'm going to do spidering/aggregating so it'd be nice to have the framework set up to support storing a record of each image in the database along with some metadata I calculate.

The image isn't saved to the database it will be saved to your servers filesystem according to your upload_to and media_url

Wulfeh fucked around with this message at 22:38 on Jun 3, 2008

# ? Jun 3, 2008 22:24

No Safe Word: Feb 26, 2005

How fuzzy is it going to be? Are you only interested in exact search string matches? Or stuff that "kinda looks like it"? It might be something that you just pick a solution and run with it for a while to see if you hit a wall. My gut tells me it should be a separate model, but I'm having a tough time coming up with the best structure for it.

# ? Jun 3, 2008 22:36

Sock on a Fish: Jul 17, 2004; What if that thing I said?

No Safe Word posted:

How fuzzy is it going to be? Are you only interested in exact search string matches? Or stuff that "kinda looks like it"? It might be something that you just pick a solution and run with it for a while to see if you hit a wall. My gut tells me it should be a separate model, but I'm having a tough time coming up with the best structure for it.

Exact strings matches would be best. It's a pretty focused tool, where people are going to make lots of the same queries over and over again. I'm also toying with the idea of not only weighting based input from the entire userbase, but individual users, as well. If I go with a separate model, I'd just need to add a single attribute to the model.

The tag-like structure was the other option I was considering, but after more thought I think a separate model would be best. Something like:

code:

class Item(Models.model):
   attr1 = Models.CharField(max_length=60)
   ...

class ItemQuery(Models.model):
   item = Models.ForeignKey(Item)
   query = Models.CharField(max_length=60)
   user = Models.ForeignKey(User)

Then I'd have either a system of methods or some logic in my views that weights things appropriately when ordering search results.

# ? Jun 3, 2008 22:52

No Safe Word: Feb 26, 2005

Oh man, opportunity of a lifetime:

gently caress this job, I'm gonna go become a CTO!

So, since it's obviously spam for email addresses harvested from a Django-centric site ... anyone else get this?

# ? Jun 4, 2008 23:27

bitprophet: Jul 22, 2004; Taco Defender

Yes

Also, I started learning Rails in earnest today. Not really blown away...has some neat ideas, and some pretty silly ones too (plus the usual warts that everything including Django has, i.e. occasional inconsistencies). Still, looking forward to being able to really contrast the two as I learn more, and at any rate it HAS to be better than the PHP crap I've been doing lately.

# ? Jun 5, 2008 01:09

ATLbeer: Sep 26, 2004; Über nerd

Just want to bump with the 1.0RC Roadmap and Timeline

http://groups.google.com/group/django-developers/browse_thread/thread/5ce124e7526dad

quote:

This is a call for comments on the proposed Django 1.0 roadmap and schedule.
Note that though this is worded in the future perfect tense, it is only a draft;
I'm looking for feedback and comments from the community before the core
developers and I post a the final version of this document (which I will do
over the weekend).
What's will be in 1.0?
======================
The primary reason we've not yet released 1.0 is the long feature
wish-list. We need to balance this list of features against the need
for a timly release and speedy process. To that end, we'll categorize
all the features of 1.0 thusly:
* Must-haves: features that, if not completed, are worth delaying the
release. That is, if the work on this list is not completed by a
release date, we'll push the date.
This of course means that these features are the "A" features, and we'll
ask anyone who can help to focus on these features *first*.
* "Maybe" features: things that *should* be in 1.0 and should be worked on
in the run up to the release. If, however, features on this list aren't
completed, they will be dropped.
* "No" features: things that specifically will *not* be in 1.0, and which
we'll ask developers not to focus on. We need to trim down to hit dates,
after all.
Must-have features
------------------
1. ``newforms-admin``.
It's clear from discussion on this list that most consider a release without
``newforms-admin`` to be a bad idea. Further, ``newforms-admin`` is nearly
done; we've already started talking about merging it to trunk.
2. Replacement of ``oldforms`` throughout Django.
Nothing in Django 1.0 should rely on the deprecated ``oldforms`` package.
We'll need to replace ``oldforms`` usage in generic views, and in
``django.contrib.auth``
``django.contrib.comments`` still uses ``oldforms`` as well, but there's
special situation here; see below.
3. Making Django 100% WSGI compliant.
This simply involves fixing ticket #285. We've delayed doing this to avoid
the backwards-incompatible change, but we must make this change before 1.0.
"Maybe" features
----------------
Again, these are features that *should* be in 1.0. In most cases, they're
actively being worked on by members of the development community and simply need
focus by committers (more about how that process will work below).
These features are arranged in *rough* order of importance.
1. Signal performance improvements (#6814).
2. Large file uploads (#2070).
3. ``INSTALLED_APPS`` refactoring (i.e. ``app()`` objects) (#3591).
4. File storage refactoring (#5361).
5. Model-level validation (#6845).
6. Full ``GenericForeignKey`` support in newforms-admin (#4667).
7. Land GeoDjango as ``django.contrib.gis``.
8. Many-to-many intermediates (#6905).
9. Fix all known bugs preventing Django from running on alternate Python
implementations. In practice this means fixing any bugs filed before 1.0 beta
from people working on running Django on an alternate VM.
10. De-cruftify custom template tag loading (including removing custom template
tag ``__path__`` hacking) (#6587, etc.).
11. Better support for controlling middleware ordering (#3591).
12. Syntax for self-referencing fields in queries (#7210).
13. Finish documentation refactoring.
Features not in 1.0
-------------------
Unfortunately, the only way to get this done is to say no a lot. Let's start
now:
1. Aggregation support. Although this is a Summer of Code project that's looking
*very* promising, the timeline for SoC won't fit with the aggressive schedule
we're setting for 1.0. Further, it's a "dangerous" change in that it modifies
parts of Django's query engine, and that needs to be rock-solid for a 1.0
release.
The good news is that it'll make a kick-rear end 1.1 feature!
2. Any other additions to ``django.contrib``. Though there are many nice
candidates out there, we simply don't have time to roll them into Django
in time for a release. We'll come up with a "contrib process" post-1.0
and start looking at this then.
3. Any additional database backends. Again, the overhead in integrating a new
database backend is too much. These will need to remain external backends
until after 1.0.
4. Any features not on this list.
We want to ship bug-free, so we'll dedicate as much of our time to bug
stomping as possible. This means that feature requests will need to be
deferred.
Schedule
========
Django 1.0 will be released in early September.
The general release process will be:
* An alpha release containing all must-have features, but likely not
bug-free. We'll push hard to have all the must-haves done in time
for ample testing.
The alpha release will also promote any "pending deprecation" warnings to
full-blown deprecation warnings.
* Two beta releases.
All "maybe" features must be completed by the first beta; after that,
Django will enter feature freeze for about a month while we kill bugs.
* At least one -- and hopefully only one --release candidate. The candidate
release will mark a total freeze (as well as a string freeze for
translators); only outright bug fixes will be accepted past this point.
* A final release.
* A big loving party.
We will hold development sprints in between each release to focus on the next
release.
Dates
-----
July 10-12 ``newforms-admin`` sprint in person at EuroPython and around
the world in IRC.
July 18 or 19 Push to 1.0 alpha sprint in the San Francisco area, and in IRC.
July 20 **1.0 alpha.**
August 1 or 2 Push to beta sprint in Lawrence, and etc.
August 5 **1.0 beta 1.**
August 8/9 Push to beta 2 sprint, location TBA.
August 12 **1.0 beta 2.**
August 15/16 Release candidate sprint, location TBA.
August 19 **1.0 rc 1.**
August 22/23 Final release sprint, location TBA.
August 26 Earliest possible 1.0 release date, or perhaps rc2.
September 2 **1.0**
All the releases until 1.0 will be "snapshot" releases: we won't be backporting
fixes -- even security fixes -- but will just be fixing bugs in the next
release.
Process
=======
Each feature on the list (both "must-have" and "maybe") gets a "lieutenant" (to
steal of term from the Linux community) and a committer assigned. It's OK if
this is the same person, but the idea is that one committer can keep an eye and
commit from patches from a number of trusted lieutenants. In most cases, the
features on the todo list have obvious lieutenants; we'll need to assign missing
ones and also committers. I'll start putting together this list tonight; right
now it's mostly in my head.
James, as the release manager, will be in charge of keeping the schedule. He'll
keep track of who's working on what issues so that bug reports can be
efficiently routed; he'll also nag, cajole and (if necessary) berate developers
who are in danger of missing deadlines.
Once 1.0 is out we'll appoint a "version manager" (thanks for the idea, Rob).
This person will be responsible for maintaining the 1.0 release series, which
means backporting security fixes and "important" bugs and releasing 1.0.1, etc.
Similarly, as soon as we have a volunteer we'll appoint a 0.96 version manger
who will do the same with 0.96. We'll continue to support 0.96 until 1.1 ships.
With the 1.0 release, however, we will stop support 0.95 and earlier. This is
somewhat flexible; if someone has a stake in one of those older versions we'll
happily let them continue to maintain those releases, but if nobody steps up the
core team won't be able to do it.
--------------------------------------------
Comments are, of course, highly welcome. Fire away.
Jacob

# ? Jun 12, 2008 23:13

hey mom its 420: May 12, 2007

Yeah saw this today, looks pretty cool. I just hope that after 1.0 they'd release versions more often. I might even contribute a bit over the summer, try fixing some bugs, etc.

# ? Jun 13, 2008 00:01

politicorific: Sep 15, 2007

Has anyone taken another look at Google's appengine? The thread is gone, but they've opened up to anyone (I never got a NOTIFY ME email). Their count is 80,000 people signed up.

Faced with the predicament of spending more to upgrade my host to deploy my django app ($10/month for ssh), I decided to start porting my project over to appengine. It's been sort of a pain, a lot of modules use functionality which isn't supported by appengine, but the biggest headache has been this:

Using GQL - google's proprietary database. Upgrading from an existing database is a huge pain in the rear end/or I'm just stupid.

I emailed a guy with some decent tutorials about django and appengine after running into some trouble, he wrote this:
http://thomas.broxrost.com/2008/06/15/porting-legacy-databases-to-google-app-engine/
http://code.google.com/appengine/articles/bulkload.html
So after exporting to a csv file you upload the data to google. One problem: it doesn't natively support unicode in the uploading tool
http://code.google.com/p/googleappengine/issues/detail?id=157

So I'm getting this error:

code:

['Traceback (most recent call last):\n', '  File "C:\\PROGRA~1\\Google\\google_a
ppengine\\google\\appengine\\ext\\bulkload\\__init__.py", line 377, in Load\n
 new_entities = loader.CreateEntity(columns)\n', '  File "C:\\PROGRA~1\\Google\\
google_appengine\\google\\appengine\\ext\\bulkload\\__init__.py", line 228, in C
reateEntity\n    entity[name] = converter(val)\n', "UnicodeEncodeError: 'ascii'
codec can't encode characters in position 0-7: ordinal not in range(128)\n"]
ERROR    2008-06-19 01:48:54,828 bulkload_client.py] Import failed

this is from a single 19 byte entry and it's driving me insane

# ? Jun 18, 2008 18:07

chocojosh: Jun 9, 2007; D00D.

A friend of mine asked me to make her a simple e-commerce site. Something similar to etsy (she can post various pieces of art online, she can categorize the art into different sections, people can view different sections, sort by price/date/category, view pictures + thumbnails). Very simple site overall. Payment would be done through paypal so I wouldn't even have to worry too much about that.

I'm imaging the bulk of the work would be something like:

<Take some user search criteria to get a list of product IDs> (e.g. "20 most recent products in X category).
<Iterate over the list of IDs and foreach ID spit out some HTML code>.

And of course an admin interface so the artist can add her new artwork items.

I've done a bit of similar work in php, but I'm not very good in php and I'd like to take the opportunity to learn a framework for future web projects. So a few basic questions (I apologize if they are in the OP) -- please feel free to give me appropriate links:

1) Is Django an appropriate tool?
2) Any major differences between Django and rails?
3) How much Python do I need to know for Django? I've spent a few days looking into pygame and wrote a few hundred lines of code but I'm not familliar with "the python way" of doing things.
4) How long will it take me "to get up to speed" with Django?
5) Any deployment issues I should be aware about with her webhost? Their site says they support python. Do they need to add extra modules for Django?
6) Any warnings/gotchas I should know about?

# ? Jun 26, 2008 19:08

king_kilr: May 25, 2007

chocojosh posted:

1) Is Django an appropriate tool?
2) Any major differences between Django and rails?
3) How much Python do I need to know for Django? I've spent a few days looking into pygame and wrote a few hundred lines of code but I'm not familliar with "the python way" of doing things.
4) How long will it take me "to get up to speed" with Django?
5) Any deployment issues I should be aware about with her webhost? Their site says they support python. Do they need to add extra modules for Django?
6) Any warnings/gotchas I should know about?

1) Yes
2) Probably, I don't know much about rails
3) You'll learn quickly enough

4) Not terribly long
5) Maybe, if it's shared hosting you might have a problem, check out http://djangofriendly.com/hosts/ for hosting reviews
6) Go use satchmo: http://www.satchmoproject.com/

# ? Jun 26, 2008 20:36

WickedMetalHead: Mar 9, 2007; /dev/null

python is fairly easy to pick up to learn Django.

The major differences between rails and Django is that Django tries not to assume anything, and instead want's you to specify more things. Rails is more "magic" where things just happen.

The django tutorial is also really good. And it shows you the low level methods of doing things, then it shows you the shortcuts.

# ? Jun 27, 2008 01:48

checkeredshawn: Jul 16, 2007

In main/models.py when I use def __unicode__(self) instead of def __str__(self) in the Admin interface everything is just a "BlogPost object" or a "Category object", they don't show as the names that I've assigned to them, i.e. 'General' (example of a Category) or 'First blog post' (example of a BlogPost). Is there a way around this?

# ? Jun 30, 2008 21:55

hey mom its 420: May 12, 2007

What does the method look like, exactly? Also make sure you are using unicode strings when returning. So don't return 'something', instead, return u'something'. The u in front of the quote means it's a unicode string.

# ? Jun 30, 2008 22:10

No Safe Word: Feb 26, 2005

checkeredshawn posted:

In main/models.py when I use def __unicode__(self) instead of def __str__(self) in the Admin interface everything is just a "BlogPost object" or a "Category object", they don't show as the names that I've assigned to them, i.e. 'General' (example of a Category) or 'First blog post' (example of a BlogPost). Is there a way around this?

code:

    __str__ = __unicode__

(half-kidding, this is a workaround at best)

Though I thought it had all been fixed already, are you sure you're using the latest trunk? Not some branch where admin isn't fixed?

# ? Jun 30, 2008 22:22

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

make sure you're using .97 (SVN) otherwise Admin won't work right with unicode.

# ? Jun 30, 2008 22:35

checkeredshawn: Jul 16, 2007

Edit: never mind, doing what ^^^ said.

# ? Jun 30, 2008 22:39

hey mom its 420: May 12, 2007

Yes, definitely! Get the SVN release, 0.96 is pretty much archaic. I bet upgrading to the latest version will fix that for you or I'll eat a spider. Don't toxx me on that though.

# ? Jun 30, 2008 22:41

checkeredshawn: Jul 16, 2007

Bonus posted:

Yes, definitely! Get the SVN release, 0.96 is pretty much archaic. I bet upgrading to the latest version will fix that for you or I'll eat a spider. Don't toxx me on that though.

It's your lucky day! Unless you enjoy eating spiders, that is. I checked out the latest version and now I've got 0.97-pre-SVN-unknown.

Although I'm confused why http://www.djangoproject.com/documentation/install/ tells you to check out django-trunk then make a symbolic link in Python's site-packages directory to the directory you checked out django's code into, when you can just check out the code and copy django-trunk/django into /usr/local/python2.5/site-packages and then copy django/bin/django-admin.py into /usr/bin. I wonder if I'll still be able to update the code using svn update this way?

# ? Jun 30, 2008 23:05

jarito: Aug 26, 2003; Biscuit Hider

Quick question. I was reading up on the Sites framework and I had a quick question. I have a set of sites that I want to run on the same DB and share the same Models, how would I go about setting that up?

When I do startproject I get the settings, manage and urls files. Then under that I create an app that has views / models. To share the models, do I create my sites as sub-projects of the project or do I create multiple projects and somehow include the models file?

So, this:

code:

/myapp
   - settings.py
   - manage.py
   - urls.py

   /myproject-1
      - models.py
      - views.py
   /myproject-2
      - models.py (uses the models from myproject-1)
      - views.py
   /myproject-3
      - models.py (uses the models from myproject-1)
      - views.py

or this:

code:

/myapp
   - settings.py
   - manage.py
   - urls.py

   /myproject
      - models.py
      - views.py
      /sub-project-1
         - views.py
      /sub-project-2
         - views.py

# ? Jun 30, 2008 23:17

hey mom its 420: May 12, 2007

checkeredshawn posted:

It's your lucky day! Unless you enjoy eating spiders, that is. I checked out the latest version and now I've got 0.97-pre-SVN-unknown.

Although I'm confused why http://www.djangoproject.com/documentation/install/ tells you to check out django-trunk then make a symbolic link in Python's site-packages directory to the directory you checked out django's code into, when you can just check out the code and copy django-trunk/django into /usr/local/python2.5/site-packages and then copy django/bin/django-admin.py into /usr/bin. I wonder if I'll still be able to update the code using svn update this way?

Haha! Nice.

It's better to make a symbolic link from the site-packages directory because then uninstalling Django is as easy as removing the symbolic link and you can update your copy of Django from the trunk without being a super user, you just go into the trunk directory and do svn update.

# ? Jun 30, 2008 23:24

Allie: Jan 17, 2004

Bonus posted:

Haha! Nice.

It's better to make a symbolic link from the site-packages directory because then uninstalling Django is as easy as removing the symbolic link and you can update your copy of Django from the trunk without being a super user, you just go into the trunk directory and do svn update.

Not really. For deployment situations you should deploy it using distutils like any other Python package. If you want to do development without installing it you can add it to your PYTHONPATH. If you're one insane crazy dude and you're trying to target multiple versions of Django across apps, you should insert them into sys.path with your runner/WSGI scripts.

# ? Jul 1, 2008 00:47

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Hey, I'm curious if anyone is playing around with Django working from a Zope (namely Zope 2, never touched 3) background. It's my first time working with a proper MVC / OO web framework, so I am tearing my brain apart moving from a more CMSy approach to code and sites to a more OO, webappy one.

The biggest concern I have is that I'm not sure how to very simply create a new page with code on it and keep things sane. I could keep adding things to urls.py, but that would get dumb and confusing quickly. Sometimes I just don't have the time or foresight (yes I am thinking about using it for work, how could you tell?) to think of a super-generic url pattern and view to use to make things compact and smart, and sometimes at the template or view layer we need to create special cases for particular pages which we can can accomplish quite easily when everything is its own file / is in a directory hierarchy like in Zope.

I'm also a little concerned about cases where I want to use parts of a Django site as more of a CMS and not a webapp, such as a landing page or some other page where the content is very user-controlled. In Zope this is obviously really easy to do. I'm not quite comfortable with just spitting out a new page with a little bit of logic, which is stupidly simple to do in Zope.

The main reason why I'm thinking of jumping the Zope boat (well it's obvious if you've ever used it) is that it's so painful to get most things done, the templating layer is waaaaaaaaaaaaaay too logic-heavy and we end up putting 80% of our code in the templates, and I don't want to have to work with Zope's bizarro internal filesystem to version my files or import whatever library I please, I just want everything to be code and thus easily able to be put into version control.

Edit: Oh! I'm so used to it that I don't notice anymore... I don't want to keep editing my source through a goddamned textarea web form like Zope forces you to do by default. True, you can set up webdav and ftp access to the zope filesystem, but it can be a hassle in particularly locked down environments where you can't just pop open a port and expect to access it from your work machine without bothering a network admin, and then having to argue with him.

nihilocrat fucked around with this message at 15:41 on Jul 1, 2008

# ? Jul 1, 2008 15:38

Allie: Jan 17, 2004

I would recommend that you stop worrying about every minute detail of your implementation and just start coding. Django isn't as in your face as Zope: you don't have to declare everything up front, you don't have to battle with the Zope server when you're editing live code and adding files, you can completely blow away your database and start over if you don't like something.

Try not to think about the framework, but think about what you're trying to solve. As you code you should begin to see what will work and what won't work. Of course, you should still think about how you generally want to solve a problem before you tackle it, but Django makes it easy to do things in a more iterative fashion.

I'd also recommend that you just stop thinking about Zope. Try not to think, "well, I know I'd do this in Zope like this." I know this can be hard when you have little context, but I think as you read documentation and read other people's code you'll get an idea of how people do things in Django - and how they don't do them. There's a lot of open source Django code available on the web, so you could actually see what specific things people did to solve problems similar to the ones you're working on. I'd recommend checking out some of the links on the DjangoResources wiki page.

# ? Jul 2, 2008 01:12

StickBoy: Jan 28, 2006

I'm just learning Django. I love it so far. I have been a big fan of python for awhile but never did much with it.
I'm having some problems in the admin class that I was wondering if you guys could help.
I am trying to make a family type model. You have the person, parents, siblings, and kids. The best way I found to do this was have a ManyToManyField("self") in the name Model for each of these.
This works just fine so far. I can add new people on the admin page. But when I try to change a person I get this error:

TypeError at /admin/main/name/4/
Cannot resolve keyword 'name' into field

Here is my model for it:

code:

class Name(models.Model):
    first_name = models.CharField(maxlength=40, blank=True,null=True)
    middle_name = models.CharField(maxlength=40, blank=True,null=True)
    last_name = models.CharField(maxlength=40, blank=True,null=True)
    suffix = models.CharField(maxlength=4,choices=SUFFIX_CHOICES, blank=True, null=True)
    gender=models.CharField(maxlength=1, choices=GENDER_CHOICES, blank=True, null=True)
    birth_state = models.CharField(maxlength=30, blank=True, null=True)
    birth_country = models.CharField(maxlength=30, blank=True, null=True)
    death_state = models.CharField(maxlength=30, blank=True, null=True)
    death_country = models.CharField(maxlength=30, blank=True, null=True)
    birth_date=models.DateField(null=True,blank=True)
    death_date=models.DateField(null=True,blank=True)
    mother=models.ManyToManyField("self", blank=True, null=True)
    father=models.ManyToManyField("self", blank=True, null=True)
    sibblings=models.ManyToManyField("self" ,blank=True, null=True)
    kids=models.ManyToManyField("self",blank=True, null=True)
    spouse=models.ManyToManyField("self",blank=True,null=True)

    class Admin:
        pass
    
    def __str__(self):
        return '%s %s %s' % (self.first_name,self.last_name, self.suffix)

# ? Jul 4, 2008 16:52

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

StickBoy posted:

TypeError at /admin/main/name/4/
Cannot resolve keyword 'name' into field

Here is my model for it:
code:
<snip>

Are you using postgreSQL by any chance?

# ? Jul 4, 2008 17:03

StickBoy: Jan 28, 2006

deimos posted:

Are you using postgreSQL by any chance?

nope. I am using mysql

# ? Jul 4, 2008 17:09

ATLbeer: Sep 26, 2004; Über nerd

StickBoy posted:

I'm just learning Django. I love it so far. I have been a big fan of python for awhile but never did much with it.
I'm having some problems in the admin class that I was wondering if you guys could help.
I am trying to make a family type model. You have the person, parents, siblings, and kids. The best way I found to do this was have a ManyToManyField("self") in the name Model for each of these.
This works just fine so far. I can add new people on the admin page. But when I try to change a person I get this error:

TypeError at /admin/main/name/4/
Cannot resolve keyword 'name' into field

Here is my model for it:
code:

Are you using .96 or SVN? There was a bug in MTM a long while back that I know has been patched and refactored in SVN. Your model looks correct in syntax.

# ? Jul 5, 2008 20:19

StickBoy: Jan 28, 2006

AtLbeer posted:

Are you using .96 or SVN? There was a bug in MTM a long while back that I know has been patched and refactored in SVN. Your model looks correct in syntax.

I am using version 0.96.2.. is that the newest version?

# ? Jul 5, 2008 22:35

hey mom its 420: May 12, 2007

No, that's an old rear end version, no one should really be using it. Use the SVN version. To do that just checkout the latest changeset by doing svn co http://code.djangoproject.com/svn/django/trunk/ and then installing it.

# ? Jul 5, 2008 22:37

StickBoy: Jan 28, 2006

Bonus posted:

No, that's an old rear end version, no one should really be using it. Use the SVN version. To do that just checkout the latest changeset by doing svn co http://code.djangoproject.com/svn/django/trunk/ and then installing it.

Thanks. It works great now. Now I can go back to learning django.

When is the next official release suppose to come out anyways?

# ? Jul 5, 2008 23:30

hey mom its 420: May 12, 2007

1.0 is supposed to come out on September the 2nd. Read more about the schedule here

# ? Jul 6, 2008 00:35

king_kilr: May 25, 2007

Bonus posted:

1.0 is supposed to come out on September the 2nd. Read more about the schedule here

There's also this nice wiki page: http://code.djangoproject.com/wiki/VersionOneRoadmap

# ? Jul 6, 2008 00:52

Adbot: ADBOT LOVES YOU

# ? May 4, 2024 21:07

Zenobia: Nov 11, 2007; i can't see the captcha image
where is it

This is probably common knowledge, but I just couldn't find the right search terms.
I'm basically following the Django book, but I'd like to know how I can include a, for example, login form in my base template and not having to repeat the code in every view that I want the user to be able to login from. Currently I just link users to a login page.
Could anyone help me with this?

# ? Jul 8, 2008 17:32

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »