|
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.
|
# ? Mar 14, 2008 02:05 |
|
|
# ? Mar 29, 2024 05:47 |
|
Anyone managed to get Django working with MSSQL? I can make little to no sense/progress with what I found while googling.
|
# ? Mar 14, 2008 03:58 |
|
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?
|
# ? Mar 16, 2008 09:23 |
|
politicorific posted:I'm trying to determine if Django is the right tool for my website: 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 |
# ? Mar 16, 2008 15:59 |
|
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?
|
# ? Mar 18, 2008 02:35 |
|
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.
|
# ? Mar 18, 2008 04:10 |
|
ashgromnies posted:and put it in my /usr/lib/python2.5/ directory(and added it to source control). I understood everything but this
|
# ? Mar 18, 2008 06:15 |
|
FrontLine posted:Ideas? code:
|
# ? Mar 18, 2008 09:32 |
|
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 All the functions in my script are required.. And they're in class form already.
|
# ? Mar 18, 2008 09:42 |
|
Oh, well then yeah, just import the stuff you need from the script and that's it. Unless I'm misunderstanding your problem somehow.
|
# ? Mar 18, 2008 09:52 |
|
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?
|
# ? Mar 18, 2008 10:26 |
|
Yeah, sure. At the beginning of your views.py, just have an import statement that imports your script, example (making stuff up here):code:
code:
|
# ? Mar 18, 2008 11:39 |
|
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.
|
# ? Mar 22, 2008 20:39 |
|
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.
|
# ? Mar 22, 2008 21:35 |
|
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.
|
# ? Mar 22, 2008 21:44 |
|
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.
|
# ? Mar 23, 2008 12:52 |
|
Digital Spaghetti posted:Funnily enough I'm working on that now in our app, but I've hit an issue. 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:
code:
code:
code:
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.
|
# ? Mar 23, 2008 16:21 |
|
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 :/
|
# ? Mar 23, 2008 20:54 |
|
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 |
# ? Mar 24, 2008 16:22 |
|
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. 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.
|
# ? Mar 24, 2008 22:07 |
|
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 |
# ? Mar 25, 2008 01:23 |
|
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. 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:
ashgromnies fucked around with this message at 18:47 on Mar 25, 2008 |
# ? Mar 25, 2008 18:28 |
|
ashgromnies posted:words Couldn't you use Middleware to do this?
|
# ? Mar 25, 2008 20:20 |
|
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!
|
# ? Mar 25, 2008 20:23 |
|
WickedMetalHead posted:Couldn't you use Middleware to do this? Not sure, I haven't looked at Middleware yet.
|
# ? Mar 25, 2008 21:26 |
|
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).
|
# ? Mar 25, 2008 22:00 |
|
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.
|
# ? Mar 28, 2008 06:14 |
|
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?
|
# ? Mar 28, 2008 18:42 |
|
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?
|
# ? Mar 28, 2008 19:34 |
|
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.
|
# ? Mar 28, 2008 19:44 |
|
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 |
# ? Mar 28, 2008 22:55 |
|
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. Today, I am that programmer. Typh fucked around with this message at 23:15 on Mar 28, 2008 |
# ? Mar 28, 2008 23:11 |
|
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".
|
# ? Mar 29, 2008 00:44 |
|
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. Anyways, back to loving Django.
|
# ? Mar 29, 2008 01:24 |
|
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. 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.
|
# ? Mar 29, 2008 15:01 |
|
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 |
# ? Mar 29, 2008 17:21 |
|
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.
|
# ? Mar 29, 2008 17:42 |
|
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.
|
# ? Mar 29, 2008 17:49 |
|
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.
|
# ? Mar 29, 2008 18:16 |
|
|
# ? Mar 29, 2024 05:47 |
|
You can consult this page: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges to see any backwards incompatible changes since .96.
|
# ? Mar 29, 2008 18:43 |