Forking a background process on request
Hi, I am working on a web app that creates reports that may take up to a minute to generate. (Or longer under heavy loads.) Ideally I would like something like this to happen: 1. User presses a button on the website. Javascript sends a begin- report-creation message to the server. 2. Report creation begins on the server in a separate process and the called view function returns "ok". 3. A bit of Javascript checks every ten seconds if the report is done. 4. If the report is done, another bit of Javascript loads it into the website for display. My question is - what is the best way of forking a separate process in step 2 to start the actual background report generation while also returning an "ok" message to the calling Javascript? Or do I even need a separate process? What sort of concurrency issues do I need to worry about? Reports are currently generated once every hour by a cron-launched Python script. This is working splendidly. Best, Elver P.S: Django is awesome! I've only been using it for a couple of days, but I gotta say, I've never been so productive with any other framework of any kind. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Forking a background process on request
Celery is exactly what I'm looking for! Thanks! :) On 4 November 2010 13:41, Brian Bouterse wrote: > I would look into django-celery to do asynchronous tasks. It can also be > executed as a webhooks style, see here. > > Brian > On Thu, Nov 4, 2010 at 3:31 AM, Elver Loho wrote: >> >> Hi, >> >> I am working on a web app that creates reports that may take up to a >> minute to generate. (Or longer under heavy loads.) Ideally I would >> like something like this to happen: >> >> 1. User presses a button on the website. Javascript sends a begin- >> report-creation message to the server. >> 2. Report creation begins on the server in a separate process and the >> called view function returns "ok". >> 3. A bit of Javascript checks every ten seconds if the report is done. >> 4. If the report is done, another bit of Javascript loads it into the >> website for display. >> >> My question is - what is the best way of forking a separate process in >> step 2 to start the actual background report generation while also >> returning an "ok" message to the calling Javascript? Or do I even need >> a separate process? What sort of concurrency issues do I need to worry >> about? >> >> Reports are currently generated once every hour by a cron-launched >> Python script. This is working splendidly. >> >> Best, >> Elver >> P.S: Django is awesome! I've only been using it for a couple of days, >> but I gotta say, I've never been so productive with any other >> framework of any kind. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > > > -- > Brian Bouterse > ITng Services > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Transactions and model.save()
Hiya! Someone raised this question in the comments of the 4th tutorial and it's been bugging me to no end. Let's take the poll sample. We've got the vote() view going on. choice.votes += 1 choice.save() Suppose we've got thread1 and thread2 going on (high-load website): choice.votes is originally 16 thread1.choice.votes += 1 thread2.choice.votes += 1 thread1.choice.save() thread2.choice.save() choice.votes _should_ be 18 now, but is it 18 or 17? Someone in #django mentioned that it'll work correctly when using PostgreSQL, but probably not when using MySQL. Our production system and my development system both use MySQL right now. PostgreSQL is an option, but I'd rather not deploy that right now. But, anyhow, isn't the point of using database-agnostic middleware like this that it'll work the same no matter what database you end up using? Anyhow, I'm just shopping for a framework right now. Django seems very very nice, but there's something about it that keeps nagging me. That's one such source of nag for me. I did some searching of the mailing list archive earlier, but I couldn't find this question answered. Or maybe I'm just too sleepy. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
i18n
Is there a way to chain languages in the i18n interface? We're using a custom Interchange tag right now to do i18n in our webstore. We support Estonian, Latvian, Lithuanian, Russian, and English. The language chaining goes something like this: if locale is estonian: print i18n(message, estonian) if that is empty: print message if locale is english: print i18n(message, english) if that is empty: print message if locale is lithuanian: # same for latvian print i18n(message, lithuanian) if that is empty: print i18n(message, russian) if that is empty: print i18n(message, english) if that is empty: print message For all others, we default to English. Is there a way to do such complex translation chaining (lithuanian -> russian -> english -> message) with Django's gettext? Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Transactions and model.save()
On 5/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 5/16/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > Let's take the poll sample. We've got the vote() view going on. > > > > choice.votes += 1 > > choice.save() > > > > Suppose we've got thread1 and thread2 going on (high-load website): > > > > choice.votes is originally 16 > > > > thread1.choice.votes += 1 > > thread2.choice.votes += 1 > > thread1.choice.save() > > thread2.choice.save() > > > > choice.votes _should_ be 18 now, but is it 18 or 17? > > You're right to point this out -- it'll probably be 17. That > particular example is a bad example; it'd be better to do "UPDATE > choices SET votes=votes+1 WHERE id=X", which would always increment > rather than setting the value directly. So the best practices workaround would be to write raw SQL instead? Hm. I can do that. I was already planning on swapping the templating engine for Kid. I like how Django's really loosely coupled :) Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Function caching
Can Django's caching framework somehow be used to cache the output of any function? What I have right now is basically a standard Django project where I've swapped out the templating engine and replaced it with Kid and where I'm not using the supplied O-R mapper, but where I've written my own DB layer. The DB layer is basically just a db.py with each app that has a set of functions for doing queries on the database. So I could do something like: from db import get_latest_books books = get_latest_books(days=7) blah.blah.output(template, books) Some of the queries are rather expensive. Some might take a couple of seconds to run. (There are 5.5 million books in the database...) Does Django offer any decorators for caching the output of any function, such as get_latest_books, based on the arguments passed to it? Or are there plans to include something like this? If not, then this would be my request. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Unhappy, reinventing
I used to code stuff with TurboGears, which started sucking rather fast. I still liked their templating engine, Kid. Sort of. I've also tried Zope 3's and Django's, a couple of homegrown ones, Interchange's as used on our big webstore and a bunch of others. As far as I'm concerned, they all have fundamental design flaws. I've outlined my problems with current templating solutions here: http://elver.cellosoft.com/2006/05/24/acceptable-use-of-programming-in-templates/ I also look at some alternatives there, including one that I'm really excited about. I think it could be integrated on top of Django rather easily, but I'm not sure if my Python-fu is up to the challenge. It's just my 2 cents, but, hell, I really really really dislike the current choices. Oh and the comments are moderated due to spam. And I'm sleepy. So it'll take some time for them to show up. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
I think I'm doing something wrong...
...because Django can't be this horribly broken. I'm sure of that much. But I've been beating my head against the wall for quite some time now and worst of all, I've got a deadline. So here's me, on the mailing list. What I'm trying to accomplish here is a simple POST form that posts to the same view. Caching is turned off. I'm not using Django's template system, but Kid. However, this shouldn't be a problem. As for the version, then I did an svn update about five minutes ago, while this same problem has also been present on the version from last night and on the version from about two weeks ago. Anyhow, the code. URL: (r'^make/$', 'latestbooks.latest.views.make_sidebar'), HTML: Ainult samal paeval ilmunud raamatud Täna ja eile ilmunud raamatud Täna, eile ja üleeile ilmunud raamatud VIEW: def make_sidebar(request): print "POST.keys()", request.POST.keys() print "GET.keys()", request.GET.keys() RESULT: [07/Jun/2006 04:50:23] "POST /make HTTP/1.1" 301 0 POST.keys() [] GET.keys() [] [07/Jun/2006 04:50:23] "GET /make/ HTTP/1.1" 200 1063 [07/Jun/2006 04:50:23] "GET /media/latestbooks.css HTTP/1.1" 304 0 I have another view working where the request.GET dictionary gets constructed properly when I pass the query string in the URL itself. (e.g., /?foo=bar&and=etc) So I don't think it's problems with any settings as such. The problem might be in my form. However, the XHTML looks valid, from what I can tell. This is driving me nuts, and I don't mean in the funny pirate joke sort of way. Help? Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: I think I'm doing something wrong...
Darn, well, that fixed it :P And to think I had the same problem with TurboGears a while bak. Sheesh. Thanks, everyone! :) Elver On 6/7/06, Max Battcher <[EMAIL PROTECTED]> wrote: > > Elver Loho wrote: > > > > Sadly it seems you, along with so many, many others, have fallen into > the easiest problem in the book. Your action address should have a > following /. > > http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata > > -- > --Max Battcher-- > http://www.worldmaker.net/ > "I'm gonna win, trust in me / I have come to save this world / and in > the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Weird behaviour
request.session seems to be storing things beyond me closing the
Django development server. This is sort of weird. Is it a feature or a
bug? Because, I'd prefer a clean slate every time I run the devserver.
Example code:
def foo(request):
foo = request.session.get("foo", None)
print "foo is", str(foo)
if foo == None:
request.session["foo"] = "Haha! Not None!"
Behaviour:
# Server started
# First run: "foo is None"
# Second run: "foo is Haha! Not None!"
# Server closed
# Server started
# First run: "foo is Haha! Not None!"
This behaviour is just way too weird. I'm currently developing with
Django for work and with CherryPy for a side project and CherryPy
doesn't store sessions beyond the lifetime of the server. I sort of
didn't expect this behaviour from Django either.
So, this a bug or a feature? And how can I turn it off?
Elver
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: Weird behaviour
On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > This behaviour is just way too weird. I'm currently developing with > > Django for work and with CherryPy for a side project and CherryPy > > doesn't store sessions beyond the lifetime of the server. I sort of > > didn't expect this behaviour from Django either. > > > > So, this a bug or a feature? And how can I turn it off? > > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting. That simply sets the cookie to expire when the browser is closed. That's not a solution since I've got Firefox open in 3-4 workspaces here, with several tabs in each instance. I'm sure as hell *not* going to close every last instance every time I change something in the code and want to start all over again... I think it's a bug that Django's session variables survive when the Django development server is closed. Yes, when I close the browser, it's nice that I can start it again and be greeted with my session. However, when I close the server, I expect the session to be lost. How can I tell Django to store the sessions in memory and drop them when the server is closed? Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Weird behaviour
On 6/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote: > > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > > > This behaviour is just way too weird. I'm currently developing with > > > > Django for work and with CherryPy for a side project and CherryPy > > > > doesn't store sessions beyond the lifetime of the server. I sort of > > > > didn't expect this behaviour from Django either. > > > > > > > > So, this a bug or a feature? And how can I turn it off? > > > > > > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting. > > > > That simply sets the cookie to expire when the browser is closed. > > That's not a solution since I've got Firefox open in 3-4 workspaces > > here, with several tabs in each instance. I'm sure as hell *not* going > > to close every last instance every time I change something in the code > > and want to start all over again... > > > > I think it's a bug that Django's session variables survive when the > > Django development server is closed. Yes, when I close the browser, > > it's nice that I can start it again and be greeted with my session. > > However, when I close the server, I expect the session to be lost. > Move beyond the development server for a moment and think about sessions > in the more general concept. The point is, I'm doing this on the development server. It's the *development* server. It's not Apache with mod_python. And in Django's docs it is said that people should not use the development server for anything but, well, development. Everything you've just said makes a lot of sense on a production rollout. Yes, do keep sessions after shutdown. It's a great feature! But this "feature" on the development server simply makes development more difficult. So, um, could someone add a feature to the SVN version to let me turn this off? Please? Pretty please? With sugar on top? :) Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Weird behaviour
On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > Everything you've just said makes a lot of sense on a production > > rollout. Yes, do keep sessions after shutdown. It's a great feature! > > But this "feature" on the development server simply makes development > > more difficult. > > > > So, um, could someone add a feature to the SVN version to let me turn > > this off? Please? Pretty please? With sugar on top? :) > > This is too much feature creep for my liking, and I don't see how it > makes development more difficult for the common case. Just put these > two commands in a shell script and off you go: > > python -c 'from django.contrib.sessions.models import Session; \ > Session.objects.all().delete()' > python manage.py runserver Hmmm... I'll do some thinking on this. Anyhow, someone said earlier that keeping session variables in the database is a good idea in case the server is shut down or crashes or whatnot. I think it's a bad idea. For the same reason. Suppose you have a controller function that sets a number of session variables throughout its execution. Suppose the server loses power or whatnot when the function is half way done. Now, half the session variables that would be set are set and in the database. The other half are not. When the server comes back on, this inconsistency in the database could cause all sorts of weird problems and bugs. Suppose the session variable "logged_in" is set to "True", but the execution stops right before "username" is set to the user's username. When the server comes back online, you have a potential security issue. It makes no sense to persist sessions beyond server lifetime. If you want to commit some change, commit it to the database. Session variables should be treated as regular variables. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Weird behaviour
On 6/8/06, Honza Král <[EMAIL PROTECTED]> wrote: > and do you really think that sessions are saved after each variable > set into the database? > I hope not... > > they are probably only saved after the return of the view, or > somewhere around that point... Alright then, my mistake. However, it still doesn't make sense to store sessions on the development server. IMO. > > On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > > > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote: > > > > Everything you've just said makes a lot of sense on a production > > > > rollout. Yes, do keep sessions after shutdown. It's a great feature! > > > > But this "feature" on the development server simply makes development > > > > more difficult. > > > > > > > > So, um, could someone add a feature to the SVN version to let me turn > > > > this off? Please? Pretty please? With sugar on top? :) > > > > > > This is too much feature creep for my liking, and I don't see how it > > > makes development more difficult for the common case. Just put these > > > two commands in a shell script and off you go: > > > > > > python -c 'from django.contrib.sessions.models import Session; \ > > > Session.objects.all().delete()' > > > python manage.py runserver > > > > Hmmm... I'll do some thinking on this. Anyhow, someone said earlier > > that keeping session variables in the database is a good idea in case > > the server is shut down or crashes or whatnot. > > > > I think it's a bad idea. For the same reason. > > > > Suppose you have a controller function that sets a number of session > > variables throughout its execution. Suppose the server loses power or > > whatnot when the function is half way done. Now, half the session > > variables that would be set are set and in the database. The other > > half are not. > > > > When the server comes back on, this inconsistency in the database > > could cause all sorts of weird problems and bugs. > > > > Suppose the session variable "logged_in" is set to "True", but the > > execution stops right before "username" is set to the user's username. > > When the server comes back online, you have a potential security > > issue. > > > > It makes no sense to persist sessions beyond server lifetime. If you > > want to commit some change, commit it to the database. Session > > variables should be treated as regular variables. > > > > > > Elver > > > > > > > > > > -- > Honza Král > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Is Django the framework I've been looking for?
Allow me to offer a dissenting view. I recently faced the task of finding a Python-based framework to use at work and tried several, including Django. I finally settled on using CherryPy with Kid. (Which is what TurboGears is doing, but with a lot of extra cruft thrown in. And btw, the TurboGears mailing list is great for tech support on CherryPy and Kid.) On 7/21/06, Sean Schertell <[EMAIL PROTECTED]> wrote: > Specifically what I'm hoping Django will do for me > = > (1) Portable apps across projects architecture. From what I've read, > it sounds like a perfect fit for what I want to do. Is it really that > great? In CherryPy, every "directory" of the website is mapped to a class with its exposed methods being the "files" in that directory. It's a godsend as you can write any kind of functionality (shopping cart, blog, whatnot) into a class or two and plop it anywhere else. Very portable and versatile. Django is somewhat more flexible (as you can map any function to any path), but CherryPy's class/method way of mapping things suits me better. It just seems more logical. Whereas Django allows you to redefine logic if needed :P > (2) Stable deployment with mod_python instead of some wonky FastCGI > jalopy. Is it *really* stable -- enough for mission critical > production environment? How about memory footprint? Can I run 100+ > Django sites on a shared server and expect smooth sailing? CherryPy provides its own server by default, which according to the CherryPy website is very stable, mature, and fast (with raw speeds comparable to Apache) but I think it can be set up using mod_python. Because Apache is faster for serving static files, we have CherryPy on a soon-to-be-in-production site sitting behind mod_rewrite so that certain folders are served by Apache. > (3) I still get to keep most of what I love about Rails. Pure object- > oriented MVC (MTV) development stucture, free stuff like form > validation, code generation, pagination, input sanitization, etc. Is > it true? What will I miss most about Rails? If you want OO, then from what I've seen, CherryPy might be a much better choice. As for free stuff, then Django certainly does all that (except code generation) and TurboGears does all that, (except code generation) but CherryPy alone does not. You could use the form validation, input sanitizaion and other needed tidbits from TurboGears. If you want them. (I really didn't need them on our CherryPy system. I'm one of those people who likes to reinvent bikes for fun :P) > Sorry for the looong post. Any feedback at all would be very much > appreciated! Before anyone flames me, then I think Django is great. It's a lot of fun to develop with and it's certainly a very capable framework with a lot of interesting new features I hadn't seen before. But it just didn't "click" for me. CherryPy seemed more mature, more stable, more minimalistic, and certainly more in tune with my programming style. But hey, I'm no expert :) Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Is Django the framework I've been looking for?
On 7/21/06, Sean Schertell <[EMAIL PROTECTED]> wrote: > > Thanks for presenting a different angle. I imagine you're one of > these long-bearded guys who uses NetBSD and Fluxbox as his main > desktop OS and edits code in VI through a tsch shell ;-) Ubuntu Dapper and Gnome. (I need Unix on commodity hardware. I need it with as little pain in the butt as possible.) SciTE for my code, though, which is pretty much just glorified Notepad with syntax hightlighting :P Just because I like to reinvent a bike here or there for fun doesn't mean I'm not lazy :P > For me? OS X and TextMate plus some well thought-out framework that > allows me to get from A to Z in __as little time as possible__. I'll > re-invent stuff if necessary, but if there's some well-oiled machine > that I can find to do exactly what I want, I'd much rather use that. > Polish and cohesiveness are important to me. I'm allergic to "jalopy" > solutions with various bits all taped and stapled together (cough - > desktop Linux - cough). So for me personally, I think a framework > born of a single vision such as Django or Rails is a better fit. Yes. I, too, hate stuff that's duct-taped together. Which is why I don't use TurboGears :) Speaking of duct-tape, though. The various "magic" bits of Django seemed, to me at least, to be somewhat duct-tape-ish. Yeah, it was certainly useful being able to just set a variable and have it do something cool that you need, but it made me scared of what extra magic might be hiding under the hood that might bite me in the butt later. I think the law of leaky abstractions applies here. I'm not saying Django's bad or flawed. It's just my preference. Plus I'm by no means an expert on Django. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Duct tape
On 7/21/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Jul 20, 2006, at 9:58 PM, Elver Loho wrote: > > Speaking of duct-tape, though. The various "magic" bits of Django > > seemed, to me at least, to be somewhat duct-tape-ish. Yeah, it was > > certainly useful being able to just set a variable and have it do > > something cool that you need, but it made me scared of what extra > > magic might be hiding under the hood that might bite me in the butt > > later. > > > > I think the law of leaky abstractions applies here. > > I wonder if you could be a bit more explicit here... I can't think of > a single place where you "just set a variable and have it do > something cool", so I'd like to know more about what scares you. The admin module? http://www.djangoproject.com/documentation/tutorial2/ Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django vs TurboGears
On 7/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'm evaluating the possibility to use Django for a project, but I have > read so many comments about Django vs TurboGears and right now I am > very confused. > I installed both of them in my system and sincerelly I found that > Django is very easy to install and getting started while TG is not so > easy. Um. Last I checked, both have very clear installation instructions. Besides, does install time really matter? > Nevertheless I hesitate to trust on the Django semplicity against the > TG complexity and I'm trying to examinate some characteristics in both > of them that interest to me. If you're comparing frameworks, you also might want to check out Zope. I've tried Zope 3 myself and found it to be horrible and very un-Pythonic, but a friend of mine has been writing web applications with Zope 2 for a very long time and says that it's much better. > Django gives you an admin environment for free while TG doesn't have > such thing and I have no idea how to create it. By writing code. Of course. To be fair, TG has Catwalk, which works as a sort of makeshift admin interface, but you'll have to write your own eventually, anyway, if it's a complicated website you're building. > TG applys the pattern MVC while Django does it in a strange way. As many have said before, it's a matter of taste :) > Django doesn't use AJAX while TG uses Mochikit and JASON. ...and what stops you from using Mochikit and JASON with Django? It's like saying that you can't order ice-cream at McDonald's, because it's not part of the Happy Meal you're eating. > Django is very compact while TG is assembled with many moduls to put > together. Well, TG is pretty much a whole lot of Open Source tools and duct tape. There are advantages to having a sort of a "guiding vision" as with Django. Then again, as many things are a matter of taste, I've found that being able to swap out bits is useful and TG is more loosely-coupled, which makes it easier. That said, I've used Django with several of its parts swapped out just fine. I'm gonna do the ultimate geek thing here and compare web frameworks to science fiction series. Django is like Babylon 5. It has a guiding vision behind it and it's very coherent, very logical, with all the 5 seasons planned up front. (Except for the slight restructuring after Bruce Boxleitner was brought in at the beginning of the 2nd season / magic-removal clean-up of Django.) But TG is a bit like Star Trek -- there might be storylines that span a couple of episodes, but that's it. Each episode is pretty much on its own and the "big picture" sort of evolves over time. No real guiding vision / grand plot. > Someone of you could give me a good reason to use Django instead of TG? Set aside a weekend and write a simple application with both. Like, say, a todo-list manager. Or if you hate having to deal with dates and times, then write a very simple blog engine. I'll give you a couple of reasons to use Django, which I myself found important. * Caching framework. Simply awesome. * Autogenerated admin interface is more advanced than the Turbogears one. (Last I checked.) Still, you will have to write your own eventually. Um. That's about it. These are its clear, technical advantages over TG -- I think everything else is just a matter of taste. I'm not really qualified to say good or bad things about either of the frameworks, really. I've used both and for the last big web application I built (an admin interface for a distributed filtering application) I pretty much rolled my own -- basically many of the components from TG, but with much of the glue and unneeded parts removed. Elver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django vs TurboGears
On 7/29/06, Javier Nievas <[EMAIL PROTECTED]> wrote: > > Django does not use MVC model, it uses Model - View - Template (MVT) > model. It's similar, because an MVC view is like an MVT template, and > an MVC controller is like a MVT view. http://en.wikipedia.org/wiki/Model-view-controller#Operation -- It's the same thing, just with a different name. But to be buzzword-compliant, let's call it an n-tier architecture! ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: when is 1 != 1? (according to 'ifequal' in template)
On 8/7/06, hotani <[EMAIL PROTECTED]> wrote: > > I'm doing a comparison of a session variable and an id for a 'selected' > tag in a drop-down in a template. If I output both vars, they will both > be "1" yet 'ifequal' is still returning false. Has water stopped being > wet? While water might be wet, "water" definitely is not :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
