Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
greenskeleton
Apr 5, 2003
It's not working because of the "auto_now_add=True" in the PublishDate. If you manually create the same date for the post, it will raise an error and prompt you to change the slug.

As for how to get Django to behave probably requires a fix in Django.

Adbot
ADBOT LOVES YOU

Typh
Apr 18, 2003

LAY EGG IS TRUE!!!
Anyone managed to get Django working with MSSQL? I can make little to no sense/progress with what I found while googling.

politicorific
Sep 15, 2007
I'm trying to determine if Django is the right tool for my website:

http://politicorific.gotdns.com:8090/
try "work" "sweep"

It conjugates Hebrew verbs. There are 4800 entries, the example and many of the other sites in the examples are geared toward user created content.

Can it be done, should it be done?

bitprophet
Jul 22, 2004
Taco Defender

politicorific posted:

I'm trying to determine if Django is the right tool for my website:

http://politicorific.gotdns.com:8090/
try "work" "sweep"

It conjugates Hebrew verbs. There are 4800 entries, the example and many of the other sites in the examples are geared toward user created content.

Can it be done, should it be done?

I don't see why not...but we'd need more specific/technical info to determine if there's some aspect of it that Django would be poorly (or well) suited for. Certainly Django's fine for user created content driven sites, and I can't imagine why it would have any problems outputting Hebrew characters.

Especially given that current trunk is pretty much 100% Unicode based now; although for that concern, the question is more "how easy is it to work with Hebrew in Python" given that Django is just a handful of Python libs.

bitprophet fucked around with this message at 16:01 on Mar 16, 2008

FrontLine
Sep 17, 2003
I gave Mr. Adequate hot, steamy man love and all he bought me was a custom title!
At the moment I'm using Django as part of a small project I'm doing for shits and giggles. So far I've got a project, 'imageupload', and an app, 'image', that seems to be working well enough. What it does is offer up an upload screen to the user and allows them to, obviously, upload an image. All of this works but now I need to move onto the next part and I'm lost with how to proceed.

I have a Pythong script, separate from Django, that does a bunch of stuff to the image the user uploads. The specifics of what the script does isn't important. What I'd like to be able to do is have Django pass the file to my other script and have it kick off from there. The results are returned as 'results.xml' which are then formatted and displayed on the next webpage.

Ideas?

ashgromnies
Jun 19, 2004

FrontLine posted:

I have a Pythong script, separate from Django, that does a bunch of stuff to the image the user uploads. The specifics of what the script does isn't important. What I'd like to be able to do is have Django pass the file to my other script and have it kick off from there. The results are returned as 'results.xml' which are then formatted and displayed on the next webpage.

I have something similar, since I wrote a raw python script to be an API to twitter.com that I call in my Django application.

From what I understand, what Django calls a view is what is in most other frameworks the controller, at least from my experience in Catalyst and reading up on MVC. Django changed the names and went with Model-Template-View, which is a little weirder in my opinion, but it basically promotes thin model, thick view.

So what I did was abstracted everything in my script into a class and put it in my /usr/lib/python2.5/ directory(and added it to source control). Then, in my views.py I simply import that class, create a new instance of it, call the methods on it I need to get my output, and stash the results in the context and render a template.

I don't know if I'm doing it the "Django way" though, but it works for me and has the benefit of letting me use this API in non-Django python applications. I'm interested if there's another way I'm supposed to do this.

If you don't understand what I meant by this, I can give you code samples and an explanation more tailored towards your solution, but you should be able to see how you could adapt it to solve your problem.

FrontLine
Sep 17, 2003
I gave Mr. Adequate hot, steamy man love and all he bought me was a custom title!

ashgromnies posted:

and put it in my /usr/lib/python2.5/ directory(and added it to source control).

I understood everything but this :)

hey mom its 420
May 12, 2007

FrontLine posted:

Ideas?
Kind of that ashgrommies said, only I wouldn't try to shoehorn it into a class if it doesn't need to be a class. If it's just a script that does something when execute it, I'd wrap that functionality into a function call inside the script and then in Django you can just do
code:
form your_script import the_function
and use that function in your views

FrontLine
Sep 17, 2003
I gave Mr. Adequate hot, steamy man love and all he bought me was a custom title!

Bonus posted:

Kind of that ashgrommies said, only I wouldn't try to shoehorn it into a class if it doesn't need to be a class. If it's just a script that does something when execute it, I'd wrap that functionality into a function call inside the script and then in Django you can just do
code:
form your_script import the_function
and use that function in your views

All the functions in my script are required.. And they're in class form already.

hey mom its 420
May 12, 2007

Oh, well then yeah, just import the stuff you need from the script and that's it. Unless I'm misunderstanding your problem somehow.

FrontLine
Sep 17, 2003
I gave Mr. Adequate hot, steamy man love and all he bought me was a custom title!

Bonus posted:

Oh, well then yeah, just import the stuff you need from the script and that's it. Unless I'm misunderstanding your problem somehow.

Using views.py?

hey mom its 420
May 12, 2007

Yeah, sure. At the beginning of your views.py, just have an import statement that imports your script, example (making stuff up here):
code:
from your_script import ImageManipulator
and then in the views themselves you call what you imported, maybe like so
code:
def display_some_results(request):
    results = ImageManipulator().get_results_for_image('some/path/image.jpg')
    # do some more parsing or whatever
    return render_to_response('some_template.html', {'results':results})

qwertyasdf
Nov 11, 2003

It looks like I may have a project coming up that deals with Ajax. Not like a metric ton of ajax, but a pretty fair amount. Mostly visual/organization related. Is django solid enough with ajax to still use it, or do I need to consider doing it on rails.

king_kilr
May 25, 2007

Addict posted:

It looks like I may have a project coming up that deals with Ajax. Not like a metric ton of ajax, but a pretty fair amount. Mostly visual/organization related. Is django solid enough with ajax to still use it, or do I need to consider doing it on rails.

Django has support for many different serializes(JSON, XML, etc.), there is no reason you couldn't use it, on the other hand, it won't right your javascript for you.

hey mom its 420
May 12, 2007

On our Django project, we're using jQuery and stuff works out just fine. You make views that serve the data that's requested asynchronously and then just write the jQuery to call them. Like king_kilr said, you can also use Django's serialization features in the views that are served up asynchronously. I like either serializing stuff into JSON and then reading it with the javascript or just directly sending html.

Digital Spaghetti
Jul 8, 2007
I never gave a reach-around to a spider monkey while reciting the Pledge of Alligence.

Bonus posted:

On our Django project, we're using jQuery and stuff works out just fine. You make views that serve the data that's requested asynchronously and then just write the jQuery to call them. Like king_kilr said, you can also use Django's serialization features in the views that are served up asynchronously. I like either serializing stuff into JSON and then reading it with the javascript or just directly sending html.

Funnily enough I'm working on that now in our app, but I've hit an issue.

The problem is when making a Ajax request, when I load a view because it extends the template above it and it loads in the whole page and not just the fragment.

I tried to pass a view variable from request.is_ajax() and put a {% if %} tag around the extend, it doesn't work - so what I'm having to do is create two versions of the same template, one without the extend.

It seems very anti-DRY, but I can find any other solution to it.

bitprophet
Jul 22, 2004
Taco Defender

Digital Spaghetti posted:

Funnily enough I'm working on that now in our app, but I've hit an issue.

The problem is when making a Ajax request, when I load a view because it extends the template above it and it loads in the whole page and not just the fragment.

I tried to pass a view variable from request.is_ajax() and put a {% if %} tag around the extend, it doesn't work - so what I'm having to do is create two versions of the same template, one without the extend.

It seems very anti-DRY, but I can find any other solution to it.

Yea, I don't think {% extends %} can work that way, as its use has large implications for how the rest of the template is interpreted and rendered. In fact I don't think you're even allowed to have {% extends %} anywhere but on the first line of a template file.

Would it be feasible to use {% include %} to work around it? I'm thinking the following:

base.html:
code:
<html lol>
<nav goes here maybe>
<div class="left-col">{% block one %}{% endblock %}</div>
<div class="content-col">{% block two %}{% endblock %}</div>
<footers yay>
</html lol>
An average template in the rest of your site:
code:
{% extends "base.html" %}
{% block one %}Left col content!{% endblock %}
{% block two %}Main col content!{% endblock %}
The template in question, which needs to be used normally and via AJAX: it will be included for the former and rendered directly for the latter. The trick is that the contents of {% block %} will always print out normally unless overridden by a child template, so if you use {% block %} in a template that's not extending anything, no harm no foul. Let's call it 'include.html':
code:
{% comment %}No extends here!{% endcomment %}
{% block one %}blah blah left col{% endblock %}
{% block two %}blah blah content col{% endblock %}
This, then, is the template you would ask to render for your normal HTML view, let's call it 'normal.html':
code:
{% extends "base.html" %}
{% include "include.html" %}
Hope that makes sense: for the base case, when you just want your "fragment", you render include.html directly, the block tags (but not their contents!) are basically ignored, and you get your output sans any wrapper HTML or whatever's in your base template. And when you want the normal HTML view, you render normal.html, which does the extends, then includes include.html, and the block tags are then used to fill in base.html as normal.

An additional useful tidbit, if you have output in include.html that is not within the {% block %} tags it should be ignored when included in normal.html (because the extends/block setup only cares about what's inside {% block %} tags in child templates) but will print out in when rendered directly. Thus you can further customize the template to behave differently in AJAX than normally, although there's no easy way to do the reverse.

Digital Spaghetti
Jul 8, 2007
I never gave a reach-around to a spider monkey while reciting the Pledge of Alligence.
Yea, I think I've kinda got it now - it's still a bit messy, but I had to fix some inheritance and I have my AJAX fragments which contain my login, and my non-ajax stuff too. It's starting to work out.

It's a pity, as some PHP frameworks I've used are able to handle this no problem :/

ashgromnies
Jun 19, 2004
I'm kind of confused as to why you're handling it like that - why don't you force your views.py to use a different content-type and print the output directly to the browser depending on what they chose?

I know in the Catalyst framework for perl you can do this very easily, so that every view gets routed through an "end" method where you can check parameters(i.e. check which view they requested - html, json, xml, plaintext, etc.) and output the data depending on that.

I'd assume there's an easy way to make a generic method like that in Django but I haven't investigated.


EDIT: You know what... I love Django and the philosophy behind it but it's just not giving me what I need for development. I like working on things on the fly and implementing new features incrementally and Django offers no way to do that.

Sure, there's django-evolutions but I haven't gotten it to actually modify my tables - it always gives some cryptic error and I don't particularly feel like diving into it so I always end up wiping my database and resyncing.

I think I'm going back to Catalyst until Django gets a little bit more ready. I understand it's still not 1.0 yet, but the fact that you can't modify a model after it's been installed is a major sticking point for me.

ashgromnies fucked around with this message at 21:32 on Mar 24, 2008

No Safe Word
Feb 26, 2005

ashgromnies posted:

EDIT: You know what... I love Django and the philosophy behind it but it's just not giving me what I need for development. I like working on things on the fly and implementing new features incrementally and Django offers no way to do that.

Sure, there's django-evolutions but I haven't gotten it to actually modify my tables - it always gives some cryptic error and I don't particularly feel like diving into it so I always end up wiping my database and resyncing.

I think I'm going back to Catalyst until Django gets a little bit more ready. I understand it's still not 1.0 yet, but the fact that you can't modify a model after it's been installed is a major sticking point for me.

The best way around that that I've found is to use the initial fixtures support, and just constantly dump/reload your database after schema changes. It's not perfect, but it works and isn't a lot of hassle. I do agree that it is a bit of a pain to have to introduce schema updates using the current setup otherwise.

bitprophet
Jul 22, 2004
Taco Defender

ashgromnies posted:

you can't modify a model after it's been installed is a major sticking point for me.

I'm guessing you're not that great at SQL? I don't mean that in a mean sense - just that anyone who's intermediate with SQL would think absolutely nothing of 1) add or modify Django model field, 2) Execute a couple of ALTER TABLE statements or drop/create db and syncdb, 3) reload Apache, 4) test out new feature.

Having automagic schema evolution would be great, obviously, but doing it by hand is not difficult.

So I guess I just take issue with you claiming Django has "no way to implement features incrementally" - that's hogwash, I and thousands of others do it daily. It just doesn't go the extra mile to insulate people from having to know their database, and if that's something that you value, that's cool (again, I think Django should have the option to generate SQL updates) - just please don't frame it as the framework lacking something integral to Web development, which it does not.

bitprophet fucked around with this message at 01:25 on Mar 25, 2008

ashgromnies
Jun 19, 2004

bitprophet posted:

I'm guessing you're not that great at SQL? I don't mean that in a mean sense - just that anyone who's intermediate with SQL would think absolutely nothing of 1) add or modify Django model field, 2) Execute a couple of ALTER TABLE statements or drop/create db and syncdb, 3) reload Apache, 4) test out new feature.

Having automagic schema evolution would be great, obviously, but doing it by hand is not difficult.

So I guess I just take issue with you claiming Django has "no way to implement features incrementally" - that's hogwash, I and thousands of others do it daily. It just doesn't go the extra mile to insulate people from having to know their database, and if that's something that you value, that's cool (again, I think Django should have the option to generate SQL updates) - just please don't frame it as the framework lacking something integral to Web development, which it does not.

I am very good with SQL, actually, I've been doing it for years - I just think that the framework should manage that for you. It seems like manually going into the database and altering the tables that it created for you goes against the idea and philosophy of the framework.

I also don't like the lack of a good DRY philosophy by implementing some sort of pre- and post-request methods for views. Maybe the functionality exists and I just haven't discovered it, but here's an example of a sticking point: Developing a RESTful Django application.

http://code.google.com/p/django-rest-interface/ is the implementation I'm going by.

This requires you to make a change for each model you have in order to make it exposed to be accessible in a RESTful manner. You need to alter both the model and the urls file.

code:
Step 4: For every model you want to be part of the API, create a Collection instance in urls.py (see more elaborate examples):

mymodel_resource = Collection(
    queryset = MyModel.objects.all(),
    responder = XMLResponder()
)
Couldn't that be genericized as to provide a much easier way to do this, then on the view post-processing redirect the user to whichever format of view they requested, rather than requiring the developer to specify a REST url for each file format for each model - once you have 4 different file formats and 5 models you want to expose, things start getting tedious.

ashgromnies fucked around with this message at 18:47 on Mar 25, 2008

WickedMetalHead
Mar 9, 2007
/dev/null

ashgromnies posted:

words

Couldn't you use Middleware to do this?

king_kilr
May 25, 2007
You seem to be willfully ignoring the fact that this is python, you can write code, if you have to do a task several times write a function, use a loop!

ashgromnies
Jun 19, 2004

WickedMetalHead posted:

Couldn't you use Middleware to do this?

Not sure, I haven't looked at Middleware yet.

bitprophet
Jul 22, 2004
Taco Defender

ashgromnies posted:

Not sure, I haven't looked at Middleware yet.

Yea, Django middleware is designed to run before/after every request/response as well as offering a couple of other spots to plug into. I haven't looked at that third-party RESTful stuff, but from what you're saying you should definitely look into the process_view (pre-view) and process_response (post-view) middlewares here (top of the page will give you an intro to middleware in general).

Typh
Apr 18, 2003

LAY EGG IS TRUE!!!
How/where do I turn off the conversion of linebreaks to paragraphs in the admin interface (TextField)? I just want a nice clean HTML-capable textarea.

bitprophet
Jul 22, 2004
Taco Defender

Typh posted:

How/where do I turn off the conversion of linebreaks to paragraphs in the admin interface (TextField)? I just want a nice clean HTML-capable textarea.

What exactly do you mean? AFAIK TextField should not be doing anything special when it displays in a template unless you pipe it through the 'linebreaksbr' or similar template filters. Where exactly is it changing line breaks to paragraphs - where is your inputted text displaying?

Typh
Apr 18, 2003

LAY EGG IS TRUE!!!

bitprophet posted:

What exactly do you mean? AFAIK TextField should not be doing anything special when it displays in a template unless you pipe it through the 'linebreaksbr' or similar template filters. Where exactly is it changing line breaks to paragraphs - where is your inputted text displaying?
The admin interface automatically converts line breaks to paragraphs when it saves to the database, as far as I can tell. When I put in my own paragraphs, there are extra p tags strewn around that aren't from me.

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
any north-jersey/nyc-metro area junior django developers want a job shoot me an email and I'll pass along your resume, my company is hiring two or three.

bitprophet
Jul 22, 2004
Taco Defender

Typh posted:

The admin interface automatically converts line breaks to paragraphs when it saves to the database, as far as I can tell. When I put in my own paragraphs, there are extra p tags strewn around that aren't from me.

That can't be right - a literal, normal TextField should save plain text to the database 100% literally, with zero HTML whatsoever unless you've entered it yourself.

Where are you viewing "the database" exactly? I'm guessing that the P tags are getting inserted by some post-database process, or by whatever tool you use to view the source (e.g. Firebug's HTML viewer seems to 'tidy' the HTML and might end up appearing to insert extra tags like that).

But, again, a normal, unaltered (meaning no save() override in the model or anything) TextField should never be performing any sort of transform on your data, period. So something else should be going on here.


StabbinHobo, you don't work in the journalism field, do you? Not at a paper in JC perhaps?

bitprophet fucked around with this message at 23:00 on Mar 28, 2008

Typh
Apr 18, 2003

LAY EGG IS TRUE!!!

bitprophet posted:

That can't be right - a literal, normal TextField should save plain text to the database 100% literally, with zero HTML whatsoever unless you've entered it yourself.

Where are you viewing "the database" exactly? I'm guessing that the P tags are getting inserted by some post-database process, or by whatever tool you use to view the source (e.g. Firebug's HTML viewer seems to 'tidy' the HTML and might end up appearing to insert extra tags like that).

But, again, a normal, unaltered (meaning no save() override in the model or anything) TextField should never be performing any sort of transform on your data, period. So something else should be going on here.


StabbinHobo, you don't work in the journalism field, do you? Not at a paper in JC perhaps?
Holy poo poo you're right. I loving hard-coded them into the template. Firefox/bug "tidied" them, turning one broken set of tags into two, giving me the illusion that paragraph tags were stuffed in all over the place.

Today, I am that programmer.

Typh fucked around with this message at 23:15 on Mar 28, 2008

bitprophet
Jul 22, 2004
Taco Defender

Typh posted:

Today, I am that programmer.

Nah, everyone does this, and more often than they admit. It's part of the job, we have so many different scenarios and environments and variables (in the non code sense) floating around that it's stupidly easy to make silly mistakes like that.

The trick is not spending too long chasing any one "bug"...we tend to get like bulldogs and latch onto a single issue and beat our heads on it for extended periods. If the entire bug hunt is predicated on a mistake, we've just wasted hours of our time (experience talking here :() so it's good to develop a habit of "ok I just passed the two-hour mark without making much real progress - time to take a step back and try a different approach".

Typh
Apr 18, 2003

LAY EGG IS TRUE!!!

bitprophet posted:

Nah, everyone does this, and more often than they admit. It's part of the job, we have so many different scenarios and environments and variables (in the non code sense) floating around that it's stupidly easy to make silly mistakes like that.

The trick is not spending too long chasing any one "bug"...we tend to get like bulldogs and latch onto a single issue and beat our heads on it for extended periods. If the entire bug hunt is predicated on a mistake, we've just wasted hours of our time (experience talking here :() so it's good to develop a habit of "ok I just passed the two-hour mark without making much real progress - time to take a step back and try a different approach".
I was digging through the admin code, running from file to file, function to function, trying to track down where it was coming from. Why didn't I check the database to see if it was really there.

Anyways, back to loving Django.

bitprophet
Jul 22, 2004
Taco Defender

Typh posted:

I was digging through the admin code, running from file to file, function to function, trying to track down where it was coming from. Why didn't I check the database to see if it was really there.

Anyways, back to loving Django.

That's another semi mantra of mine (and no doubt lots of people with way more experience), "always double check your assumptions". Assumptions, especially in programming, are killers.

qwertyasdf
Nov 11, 2003

So is everyone using the .96 release of django or the latest on subversion. When looking to extending the admin panel they keep saying they want to overhaul it with newforms and such. It seems like a few things are in limbo at the moment. I have been sticking to .96.

qwertyasdf fucked around with this message at 17:23 on Mar 29, 2008

Allie
Jan 17, 2004

Addict posted:

So is everyone using the .96 release of django or the latest on subversion. When looking to extending the admin panel they keep saying they want to overhaul it with newforms and such. It seems like a few things are in limbo at the moment. I have been sticking to .96.

You should always use trunk, since that's what gets bug fixes and new features. They still reserve the right to break APIs, but that rarely happens now, and it's always thoroughly documented. The version releases are just for crazy people who value "feature stability" over everything else.

bitprophet
Jul 22, 2004
Taco Defender

Addict posted:

So is everyone using the .96 release of django or the latest on subversion. When looking to extending the admin panel they keep saying they want to overhaul it with newforms and such. It seems like a few things are in limbo at the moment. I have been sticking to .96.

0.96 versus trunk is an odd case; obviously 0.96 is very stable and trunk does change fairly often-ish (although rarely breaking backwards compat, and always well documented when it does). However, 0.96 is over a year old at this point and there are a lot (as in A WHOLE LOT) of new features and concepts and so forth, in trunk, which aren't in 0.96 at all.

If you stick with 0.96 and wait for e.g. 1.0 to come out (whenever that is; nobody knows; I'm guessing within 3-6 months or so) there will be a significant amount of work you'll need to do to upgrade your codebase, and in the meantime you will miss out on some vastly improved functionality (newforms, the upcoming queryset-refactor, HTML auto-escaping, url()/@permalink for DRY get_absolute_url()s, the list goes on).

So I'd only stick with 0.96 if you're developing mission-critical production software, in all honesty; plus there's no reason you have to track "the latest" if you upgrade to a trunk checkout. I tend to check out or upgrade SVN when I start a new project, when a bug is fixed or when I want to try something new - but only then. So it'll still be extremely stable but you'll reap the benefits of over a year's worth of work.

hey mom its 420
May 12, 2007

Yeah, just use the SVN version, I don't recall anything getting borked when upgrading and if they change something (like when they changed the maxlength model field option to max_length), they usually keep the old behavior and issue a deprecation warning upon usage.
Also, Django has a very good extension to the unittest module and it's pretty easy to make some basic test coverage for your code so you know immediately if something major gets broken.

Adbot
ADBOT LOVES YOU

king_kilr
May 25, 2007
You can consult this page: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges to see any backwards incompatible changes since .96.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply