Possible async view regression in django 5.0?

have never found a real bug in django so I'm still having doubts :D) Best regards /Hugo -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving

Requesting comments about bug "set_language with i18n_patterns"

6 Do any of you have any comment or need further info? Cheers, Hugo. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an e

Re: Testing pre-release Django

group and stop receiving emails from it, > send an email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django- > develop...@googlegroups.com. > Visit this group at > https://groups.google.com/group/django-developers. > To vie

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Le mardi 22 mars 2016 23:33:10 UTC+1, Shai Berger a écrit : > It is Django's job to try, as best as it can, to fulfill these expectations. How could I disagree? Of course, if there is one single sensible, obvious default, that would help 99.9 % of users, like your webserver analogy, it should

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Le mardi 22 mars 2016 00:11:31 UTC+1, Shai Berger a écrit : > I disagree. The ORM cannot keep you safe against MySql's REPEATABLE READ. >> Incidentally, to prove my point, >> this has been changed in Django 1.9 and data-loss doesn't happen anymore, >> in that same default isolation level. >>

Re: MySQL data loss possibility with concurrent ManyToManyField saves

Le lundi 21 mars 2016 13:35:19 UTC+1, Aymeric Augustin a écrit : > > > The problem is to determine what “safe” means here :-) I’m afraid this > won’t be possible in general (at least not in a remotely efficient fashion) > because Django inevitably depends on the guarantees of the underlying > da

Re: Django & django-polymorphic

nceManager, polymorphic, and generic-m2m) > https://github.com/elbaschid/mti-lightbulb > Django already uses MTI. The only difference I'm proposing is, basically, making life simpler for those wanting to get all objects as their native class, rather than parent class (while not aff

Django & django-polymorphic

this discussion be opened here, or rather as an issue over at code.djangoproject.com? Thanks, -- Hugo Osvaldo Barrera -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou

Re: slow migrations

etmigrations?) In my case, once data migrations have run in staging/production, they're useless and can be ignored forever, so there's no point in keeping them in later squashed migrations months later. -- Hugo Osvaldo Barrera -- You received this message because you are subscribed to th

Re: Vote on Jira as bugtracker

On Wednesday, January 6, 2016 at 10:09:08 AM UTC-3, Victor Sosa wrote: > > HI, > > I felt like lost using trac; it is kind of messy. I just don't feel > comfortable > with it. > I see so many open source project using Jira that is just natural. Search > is easy, categorize is easy, look throu

Re: why django 1.9 migrations are essential?

://groups.google.com/d/msgid/django-developers/50066b7e-1e16-4fb7-ae22-2c79bf37d06f%40googlegroups.com[1]. > For more options, visit https://groups.google.com/d/optout. -- Hugo Osvaldo Barrera Links: 1. https://groups.google.com/d/msgid/django-developers/50066b7e-1e16-4fb7-ae22-2c79bf37d06f%40goog

AbstractUser hierarchy and email-based-users

especially since this would let me clean up a lot of custom user models), but I'd like to know if these changes would be acceptable or not, or if there's any feedback on it first. Cheers, -- Hugo Osvaldo Barrera -- You received this message because you are subscribed to the Google Gr

Re: Django Admin New Look

On Fri, Aug 21, 2015, at 08:06, elky wrote: > Does 'title' attribute help in terms of accessibility? `title` adds a tooltip, so no, not really. -- Hugo Osvaldo Barrera -- You received this message because you are subscribed to the Google Groups "Django developers (Contr

Re: Django Admin New Look

I checked it with few CMS apps). So font approach is an extra >> headache for app developers. I see not mention of this later on this thread so I have to ask: Do we have an equivalent of an `alt` if using fonts? If not, how would this be usable by, for example, blind users? Currently, d

Rename *SSL* settings to *TLS*

EADER -> SECURE_PROXY_TLS_HEADER This should improve the ability for new users to find these settings, and reflect current practices (eg: that SSL has been completely deprecated in favour of TLS). Any opinions or complaints to this? -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right

Re: Unicodification of Django

Hi, > I think we should do this. > > We are, after all, perfectionists. > > Not only do we want to show even more love toward the international > community, I just like the idea of passing Unicode strings everywhere. > It seems so clean. I whole-heartedly agree! It's just much cleaner and actual

Re: Unicodification of Django

Hi, > So, what's stopping Django from switching to unicode? Is someone working on > it? And finally, what should I do to see my sweet Django fully > unicode-aware? :) Well, as a start, take a look at the impact analysis page at http://code.djangoproject.com/wiki/UnicodeInDjango and contribute up

Re: django irc logger currently down

Hi, > I try to find a solution - either get the provider to open up the port > again (it's rather silly to not allow root servers to use port 6667 ... > especially the client-side of it ...) or by moving the logger to a ok, luckily the IRC servers are reachable on different ports, so I could jus

django irc logger currently down

Hi, the #django IRC logger is currently down - my provider blocks port 667 now, without giving me a notice about it. That's why I didn't notice a problem until today. :-/ I try to find a solution - either get the provider to open up the port again (it's rather silly to not allow root servers to

Re: magic-removal call for testing

>By way of process - Is the plan to make a formal release after the merge, or >will the "MR Trunk" be allowed to settle a little longer before we formally >tag a release? And, to follow a previous disussion, are we going to tag the >current state of trunk as a 0.92 release reflecting all the trunk

Re: also: multiple databases

Hi, >Seriously, though -- this is obviously a very cool feature and one >that would be AWESOME to have. Even better would be able to access >the same object from multiple databases... I _think_ this could be done based on the managers - actually that's what we discussed some time earlier. The o

Re: proposal: endif, endfor etc assume whatever follows in tag is comment

>It's not clear to me that inline comments were outright rejected here. >Perhaps I missed some other discussion but to my biased eye the >general concensus was favourable. I remember several situations where Adrian and Jacob rejected an inline comment syntax (IRC, tickets, group). I found one dir

Re: proposal: endif, endfor etc assume whatever follows in tag is comment

>{% endif %}{# endif start_process #} Ugh, no. Sorry, but I am definitely -1 on this. If we want something useful, go for the {% if something %} ... {% endif something %} where the "something" on the endif is optional and if it is given, must match the corresponding if. Everything else is just s

Re: Finalizing descriptor implementation

Hi! >1) What should be the behaviour of __set__ for descriptors where >multiple values are allowed (ForeignKey, ManyToManyField)? Allow assignement of any iterator. If people are confused by the fact that a list has an order and a set doesn't, they will be confused by the fact of sets themselves

Re: What if instead of calling them "projects" we called them "sites"?

ious servers, such >as my laptop, the testing server, the production servers, etc. > >I think Hugo once mentioned he does the same thing. Yep, with my rfc1437 project I do the same. To put flesh to an abstract discussion: Many of my apps are in a different project, the ominous "stuff"

Re: Schema evolution

>I'm not sure exactly what reparations you're thinking will be possible >by rolling back a DDL transaction. I'm pretty sure most db's don't >have full transaction control over DDL. Issuing a DDL statement >usually involves at least an implicit commit, so, e.g., if something >goes wrong three DDL

Re: Jinja Template Engine

>Jinja isn't compatible with django templates. It uses a parser for the >tag arguments A parser for tag arguments is available in Django, too - not all template tags use only regexps. :-) bye, Georg --~--~-~--~~~---~--~~ You received this message because you are

Re: Proposal: Validation-aware models

>* This plan is nice conceptually because it doesn't leave any chance >of bad data in any model instance. Currently, Django is "dumb" about >data in model instances -- it allows any arbitrary data there, and >catching bad data is completely the responsibility of the developer. >This can lead to so

Re: Model API: blank=True vs. null=True for non-string fields; redundancy

>What are your thoughts on the modified proposal stated in my reply to >Luke (i.e., keep both, but have blank automatically set to True when >null=True and then allow the explicit setting of blank=False)? blank=True with implicit null=True isn't probably what users would expect when applying it t

Re: 'Rotating' the fcgi backends.

>I want to exit() a backend after it has processed a certain number of >requests via FCGI (WSGI?). Any idea how to do it cleanly with Django? I think you would have to do that by patching FLUP. I don't think you can do it easily in Django. That's mostly because you don't have a way to specify co

Re: Model API: blank=True vs. null=True for non-string fields; redundancy

>There currently seems to be a bit of redundancy with regards to the >"blank" and "null" field options; tickets #1043 and #1353 seem to be >the inverse of one another, each addressing that one must specify both >blank=True and null=True to get the expected behavior (i.e., being >able to specify an

Re: DoJo Integration & JSON methods

>I'm thinking of including simplejson (http://undefined.org/python/ >#simplejson) as Django's standard JSON library (as django.utils.json, >probably); any objections from anyone? Nope, I'm _very_ fine with that decision. I used json.py, but only because at that time simplejson wasn't there. And j

Re: Proposal: custom admin field templates

>Instead of this hook, how about just using the existing JavaScript >hook? Either that, or we can add declarative syntax to the 'class >Admin' like so: > >class Admin: >use_custom_templates = ('field_name1', 'field_name2') Heh, I like that. What I don't really like is the fact that st

Re: Bulk Delete - Take 3, descriptor style

>This variable would be set at the beginning/end of requests, and also >when switching threads in a multi threaded server, if any exist... This >way the .cached() would be unnecessary - the cache would be scoped to >the request in the web context, and caching contexts could be explicitly >set in o

Re: How about converting python config files to text config files

>You mean that you'll never want to change them. And I also made a >seconad topic about this, it's seem that you didn't notice it. What I >want just want to make django more easiler for installation, >deployment, or somethings. Have you some good suggestions about how to >simplify the changing of

Re: running 2 django versions side by side

>how do people do this? >I want to try using the magic-removal code on some of my apps >but still have access to the 'trunk' django for apps I don't want to port yet. I have a one-user-per-project layout where I have the following directories: $HOME/projects (this is in $PYTHONPATH) $HOME/projec

Re: How about converting python config files to text config files

>I'v summited a ticket http://code.djangoproject.com/ticket/1337 for this. >What do you think about? Nope, a big -1 from me. Really - full-python configs is one of the things I really liked in Django the first time I looked at it. Just try to drop the idea that configuration is something static -

Re: still some magic left in magic removal

>But have you tried getting the >above to work with magic-removal? It doesn't work for me (i.e. I can >import the models with 'from appname.models import MyModel, but the >models aren't found by django admin etc), hence my other thread 'Models >in separate files'. In that case, open up a ticket

Re: still some magic left in magic removal

>I was going through magic removal wiki page, and encountered this, I think >there is still some magic left in the Custom managers, and multiple >managerssection. I have a following objections: It's maybe not perfect, but a very good start. No one prevents later refinements - we just need somethi

Re: GvR prefers Django Template over Cheetah And Modularised Django

>a simple solution would be to use lazy loading of the settings >module in django.template, change all template code to access >the settings via django.template.settings, and let an external >user configure the template package *before* loading the first >template: Should be doable since now sett

contrib/comments and inline templates

Hi, the contrib/comments stuff contains inline templates - which are a bit of a pain if you want to apply translations. Either you would have to put in variables that will receive the translated strings, or you would have to move the templates out into files in a app-local templates/ directory. I

Re: DescriptorFields status/Manager API change

>Ah, interesting -- I hadn't thought about that situation. So >essentially a Query is a curried lookup until you iterate it, yes? Yep. >What happens to a query after it's been iterated? For example, how >does the following behave? I'd say it should memoize it's result - so it is only queried

Re: DescriptorFields status/Manager API change

>Good call about the "sites" thing. Really, that attribute name isn't >used at all (from what I can tell)...hmmm. What are your ideas? Regardless of what you do in the end: please no "magic name invention", especially if it is something like "attribute sites becomes site_set" - that way we would

Re: DescriptorFields status/Manager API change

>I'm a big fan of the "One True Way" principle, so that rubs me the >wrong way. Why not simply have order_by/distinct/etc. be kwargs to >the manager functions? If there's a good reason to do the "chained >methods" that's fine, but let's not be too clever for our own sakes, eh? One nice thing ab

Re: Magic - removal branch .. is the API stable yet?

>AFAIR unicodefication must be done before Django 1.0. This not big API >change, but some code must be changed too after it. >(Ex. str->repr or str->unicode) Before doing it, there still is the analysis of what needs exactly to be done - for now it's just a list of keywords on the wiki page, I de

Re: Extending Django: "Adaptation" via Generic Functions

>For instance with manipulators, after magic-removal, it will be >elementary to over-ride the Model.AddManipulator(), and >Model.ChangeManipulator(pk). So you could then apply RuleDispatch in >your own model, and not need it built-in to Django at all. You can only override methods that are defin

Re: Making models validation-aware

This: >What I'm suggesting is that validation only happens when you do >save(), or when you access the "errors" attribute. This means you can >set data on the model to your heart's content until you actually want >to validate it. won't work with that: >This is a good question. I don't see a *hu

Re: Magic - removal branch .. is the API stable yet?

>Up until today I could even run both branches of >code against the same database, but that changed tonight because we've >changed the way database-table names are calculated. Ok, now I know why it was a bad idea to switch the logger to magic-removal ;-) (just kidding, it's a really simple proje

Re: Making models validation-aware

># a.errors is a property that returns a dictionary ># of field names to lists of errors. Maybe this could ># be named something else, so as not to clash with the ># field namespace -- perhaps "_errors" with a leading ># underscore. Make that a defined Exception instead of an attr

Re: Bulk delete - lets try this again...

>default manager works fine for the simple case, but how do propose to >choose the 'correct' manager if there are multiple managers involved? The objects do have some meta data - just plug a "source" meta data in there that points back to the manager from where the object was loaded? Or maybe jus

Re: Bulk delete - lets try this again...

>However, it would >mean moving some model logic into the manager, making Model.delete() >defer to the manager to collate and remove objects. Would this rub >anyone the wrong (or right) way? Actually I think sooner or later we will need objects to keep track of the manager they came from - for ex

Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)

>Doesn't the delete function also checks permissions on all the >referenced rows? I don't think you can implement this in SQL. You are talking about the admin interface - we are talking about the database API. The database API doesn't check any permissions, as it's a Python call done by the progr

Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)

>This is exactly what Django used to do, actually, back when it was >Postgres-only. Such are the compromises of having to support other >DBs. :-/ Maybe it would be a good idea to add stuff to the Django backend modules so that real databases can make use of referential integrity and cascaded dele

Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)

>I've been looking at the code for normal object deletion in an attempt >to get the same behaviour for bulk delete. It seems like there is a >lot of logic dedicated to maintaining referential integrity that the >database could be doing (and would probably do more efficiently). It's not just the r

Re: apps with the same name

>I'll admit there's something a little magic about adding "code" to a >string in the "foo as bar" proposal, but it strikes me as pretty >obvious magic. How about something like this: INSTALLED_APPS = ( 'foo.bar.baz', ('foo.baz.baz', 'baz2'), ) So essentially either provide a string - in t

Re: Using an inner class for custom Manager in magic removal branch

>+1. Gets around the reserved word problem entirely, and removes a >little bit more magic from model definitions. Problem with that discussion was, IIRC, that neither Adrian nor Jacob where very fond of allways having to explicitely provide the manager. So the result of the discussion was what we

Re: Using an inner class for custom Manager in magic removal branch

>Personally I find the idea of "every model class has an objects >property for manipulation in bulk, except when it doesn't" pretty >horrifying, especially from a code maintenance point of view. I guess >if people really want to make their lives more difficult we should >let them but I certainly w

Re: No way to get the requested hostname in a portable way

>request.META['HOSTNAME'] works for getting the host when django is >started with the builtin webserver, but doesn't work with the fcgi >backend. request.META['HTTP_HOST'] doesn't work? Because that's the common way to access the HTTP header Host: - that should work with SCGI/FCGI, too. bye, Geo

Re: Using an inner class for custom Manager in magic removal branch

[current sample with defined classes and used objects] >The above feels a little clumsy to me. Here's my proposed alternative: [sample with inner class] Uhm - in what way is nowadays defining classes and using them "clumsy"? Thought that's what OO is all about. The beast is named "removing the

Re: Proposal: Django should support unicode strings

>Looks like a typo: DEFAULT_ENCODING there is actually DEFAULT_CHARSET? Yep. Fixed it. But you could have fixed that yourself, it's a wiki ;-) bye, Georg

Re: ifequal support for AND OR

>If the templates allowed more complex logic, template designers might >be tempted to write a template that reads "if >last_payment.before(today - 1 year) and not admin". However, this >encodes a business logic decision in the template. Since the template >language does not allow complex queries,

Re: Proposal: Django should support unicode strings

>i understand the general unicode-related problems with python, i just >wanted to understand what's django specific. Since Django is written in Python, those _are_ django specific. For example several of the template filters make use of uppercase/lowercase conversions (only interesting if you can

Re: Proposal: Django should support unicode strings

>i understand that django's architecture should use unicode because it's >the better way, but from the "outside"... what functionality is not >working fine with non-english characters? There are loads of things that don't work - actually anything that has a notion of a character but get's fed wit

Re: Proposal: Django should support unicode strings

>It mentions that HTTPResponse should do unicode -> DEFAULT_ENCODING. I >think that HTTPRequest should do backward translation. Or am I missing >something why it shouldn't? Absolutely correct. That's why I asked others to join in, because I am bound to have forgotten some parts ;-) I added that

Re: Proposal: Django should support unicode strings

>I think that Django should support(use only) python unicode strings. Since the work needed would be a bit involved (not the actual work, I think, but finding and fixing all relevant places), I set up a wiki page to collect places and procedures regarding unicodefication. I think that Django sho

Re: Proposal: Django should support unicode strings

>unicodefication or the patch from #914, with my preference being the 924, that is ... bye, Georg

Re: Proposal: Django should support unicode strings

>You mean total unicodization? As far as I understand it's not >incompatibilities that hold this change but complexity. The problem is >not localized to just templates filters it would be the change across >entire code. Yep, it would be just a pain to do - loads of places need changing, all str()

Re: GUID discussion

>Any thoughts of putting this into the bin or maintenance subdir of Django >distro? There is one in the bin directory, only that script has an additional dependency on the user registrations and so won't run right away, because only ellington users will have that table. bye, Georg

Re: GUID discussion

>True. The fun thing about the recipe is that it produces keys that are >so unique that they do not need to be checked against a db. That's >where the performance benefit comes from. And I think not checking >against a db is the "other context" mentioned in the ticket. Actually it doesn't. It dep

Re: GUID discussion

>session_key = md5.new(GUID.generate() + SECRET_KEY).hexdigest() >Benefit: unique session key without the need to access the database, >really fast (more than 20.000 session key per second) >Drawback: Additional third party dependency. It's not faster than the current version - it does the same

Re: Proposal: Django namespace simplification

>I like this idea, but I think that shortcuts of whatever should use >explicit imports such as [...] >This makes it a lot easier to tell what exactly you'll get if you >import django.shortcuts. Yes, most definitely. The "simplified API importer" should only do explicit imports of the stuff that s

Re: How to handle i18n in patches?

>I have run 'bin/make-messages.py -l en' to produce changes to the >English .po file. However, it concerns me that I needed to set >DJANGO_SETTINGS_MODULE - this implies that the script is adding i18n >strings from my currently installed application, not just from my >changes to Django source. Mak

Re: magic-removal table name pluralization

>expressing an opinion. See http://www.djangoproject.com/ >documentation/contributing/#deciding-on-features for a bit more on >how we use voting in the Django community. Actually rereading that stuff, I think it would be useful to have a list somewhere where you list people with commit access an

Re: Proposal: Django namespace simplification

>One altertative to your proposal that Adrian and I tossed around at >one point was to alias certain "normal" modules into a set of >"tasks." That way writing a view would become:: +1 from me - that would allow to provide "simplified" namespaces by still keeping the basic structure in place (as

Re: Relevance of DISTINCT keyword?

>I can't see any occasion that DISTINCT isn't either redundant, or >required by design as a result of the goals of an Object-relational >mapper. Look at get_values - it will return only those columns that you specify you want to get. You need distinct=True there, if you want to get rid of duplica

Re: FileField & many to many

>Just an idea: could the file be temporarily stored in the session >instead? At least then it won't be sent "over the wire" multiple >times. Storing it in the session avoids having to introduce yet Files can be big. Don't think that it's a good idea to either send it over the wire or store it i

Re: Moving auth and core models to contrib -- and dependencies

>So a solution that Jacob and I came >up with is introducing app dependencies. The admin app, for instance, >is dependent on auth and core. The auth app is dependent on core. >There are many apps in Ellington (the World Online commercial CMS >built on Django) that depend on other ones. +1 The IN

Re: Strange error in magic-removal manipulator unit test

> the _() global translation function is getting reassigned to a >dictionary. See the test output below. Weird. Did you add a print to see _what_ is assigned to _? Maybe there is some code in there where _ is used as an anonymous variable (seen that in the code in several places) and so the built

Re: idea for magic removal - delegate all DB-IO to the manager?

>The problem is, I'm not sure what it would mean in the case where the >object is "enlisted" in a unit of work. Basically, it would be a method >with very odd semantics in the vast majority of cases ( ie running in a >webserver in Django). Agreed, that might be complicated to explain. So better j

Re: idea for magic removal - delegate all DB-IO to the manager?

>So in the usual case, this would get done implicitly by some middleware, >ie there would be a request scoped unit of work that would be used by >managers unless told otherwise, and it would call save() if the request >works, or it would discard it on an exception. Yes, that sounds good to me. >

idea for magic removal - delegate all DB-IO to the manager?

Hi, how about delegating _all_ DB-IO to the manager with magic removal? Currently all class-based selects are handled by the manager, while object-based selects and updates/inserts are handled by the objects themselves. How about internally delegating updates and object-based selects to the mana

Re: Magic removal stuff...

>One advantage we've had so far is that django has no dependencies, so >its easy to get up and running. Is there a sane way that we could >include louie with django (a snapshot in the svn?), but not in eggs, so >that the egg version will do the setuptools-ly correct thing and >download/require it?

Re: Magic removal stuff...

>The really funny thing about this: All of the examples I gave are at >least as field-like as the existing ManyToMany field. Yep, that's why I started out with the BEHAVIOUR idea in my comment on this and dropped it - in the end, most stuff you will do to a model class will either be some kind of

Re: Magic removal stuff...

Hi, >1. The class is created. >2. Any class META stuff is taken care of. This may be merged into the >next step. >3. Any remaining attributes of the class are added to the class under >their own control. If they have a method of the signature: > >contribute_to_class(self, cls, name) Hmm. I like

Re: Decoupling core Django handler from database

>This makes the assumption (currently inherent in Django) that you >will only use one database connection. This can cause problems if you >need to scale your application. Actually it only makes the assumption that it is a common case that you only manage one connection. There is nothing that woul

Re: Decoupling core Django handler from database

>However, if a person *does* use a database, we still want that >connection.close() in a finally. Adapt my idea of middleware for database transaction handling :-) Essentially if you have code outside the web app context, you handle stuff yourself. But if you are running a web application, you j

Re: magic-removal q

>Basically, promote Admin settings to a full inner class, rather than >nesting it in meta. It would still end up in meta though. +1 from me on that one. The Admin-Minilanguage within the META-Minilanguage is rather weird currently, one uses attribute=value syntax, the other uses list-of-named-par

Re: Descriptors for fields?

>reporter.articles >reporter.articles.filter(headline__startswith='This').order_by('headline') >reporter.articles.add(headline="John's second story", >pub_date=datetime(2005, 7, 29)) >article.reporter >article.reporter.id Looks good to me. bye, Georg

Re: Django Ajax Redux

>thread, but I want to point out that while I agree that a non-JS fallback is >a reasonable requirement for the Django Admin, I don't believe that a non-JS >fallback is necessarily a requirement that needs to be imposed on an "AJAX" >integration strategy. In other words, for a lot of us, the admi

Re: Django Ajax Redux

>Dojo seems to rely on adding its own unnamespaced attributes to normal >elements. Is this compatible with strict use of XHTML? That would be my biggest technical gripe (beside the missing documentation) with Dojo - (X)HTML with invented unnamespaced tags will not validate any more, and if there

Re: Django Ajax Redux

>But are we sure we want to build our own javascript framework from >scratch? Of course not, that would be rather silly. It's just much easier to decide what framework to use if you actually worked with them and solved problems with them. From my current point of view I would choose MochiKit over

Re: Django Ajax Redux

>Basically I >want to propose an implementation. At least I'll collect your thoughts, >criticism, corrections, and, hopefully, blessings. Just some thoughts from me on this: it would make much more sense to address the whole Ajax stuff from a practical point - start adding stuff to the admin that

Re: Chinese Simplified po file updated

>Three bugs were fixed in the Chinese Simplified po file - the following >three messages should not be translated: Thanks for the update, I added them to the repository. For future updates: just post a ticket to the Django ticket system and attach the .po file there. No need to attach the .mo fil

Re: Removing the magic

Somehow googlegroups ate my comment. Second try. Overall comment: "removing magic" is a bit irritating if you actually just exchange it for other magic (like query objects) ;-) >Please comment here rather than on the wiki. Two dislikes: 1) I'd prefer "manager = PersonManager('name_of_manager_a

Re: "Magic" model module change proposal

>I'm having a hard time seeing any benefit to 2 over 1, unless 1 can't be >done. >I think you want 1 (as do I), but I just couldn't quite see if that was >what you meant in the text ;-) For the records: yep, I would be happy with 1). I could live with 2), but as you I don't see any advantage over

Re: "Magic" model module change proposal

>I'm sure others can come up with other methods. I would prefer 1) >because its obvious, but don't really care as long as we get rid of the >generated class. Actually turning the model class with it's magic into one standard-behaving python class (preferably new-style) would be a really great thi

Re: "Magic" model module change proposal

>If I didn't think combining the functionality in models would confuse >people (particularly newcomers), I could probably agree with you. But >regardless, I think it's cleaner to keep these functionalities >physically separate. And you honestly think that newcomers are not confused by the fact t

Re: "Magic" model module change proposal

>Right -- the generic view infodict will change, and content types will >change as well. It's a big change, but it's important to make. Then we should maybe relase a point release just before the merge of that stuff - it will break loads of peoples apps, so maybe it would be a good idea to have "

Re: "Magic" model module change proposal

>One of the things we discussed was demagicifying the "magic" model >modules. +1 from me, even though it will be a pain to change all the code ;-) One problem I see: the Admin URLs currently can rely on being only two-level. When the listed changes are in, an app that sit's in cms.apps.cms will

Re: Cache and GET parameters

>Finally, along those lines, we could introduce a vary_on_get >decorator, which, used with the NO_GET_PARAMS setting, would be an >opt-in signifying a view *does* rely on query string. This could be >for stuff like search engines, which do vary based on the query string >(e.g. /search/?q=foo). In

  1   2   3   >