Re: does django-admin need a man page?
On Mon, 2014-11-24 at 16:44 -0800, Tim Graham wrote: > I raised the issue in #23903 and Aymeric mentioned that it may be > useful for downstream packagers, e.g. Debian. I installed > python-django via apt-get on Ubuntu 14.04 and confirmed the existence > of the man page. I'd like to remove it though (or make it point people > to 'django-admin --help') as it's out-of-date and 'django-admin > --help' provides the same information in a much easier to maintain > format. Does anyone else have input on this? > As far as Debian is concerned, not having a manpage for an executable installed in the standard path is a bug. So if you don't provide one, one will probably be written for Debian anyway, albeit not a particularly good one. However, as Ben pointed out, "man foo" is the standard interface to getting long-format information on the "foo" command, if not always the full docs (g info gr). So I'd suggest considering implementing something to generate a man page from whatever you wish the "canonical" source of the information to be. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago -- 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 email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1416963109.6414.18.camel%40otago.ac.nz. For more options, visit https://groups.google.com/d/optout.
Re: [GSoC] Revamping validation framework and merging django-secure once again
On Sun, 2013-09-15 at 18:23 +0200, Aymeric Augustin wrote: > On 15 sept. 2013, at 17:57, Simon Kern <sim...@gmail.com> wrote: > > > Yes but management commands should be irrelevant for django-secure > > Well, in this case, I have a backup argument :) > > There's a non-negligible number of people serving websites in production with > ./manage.py runserver, in spite of all the warnings in the docs. FWIW there is also a non-negligible number of people who believe in doing development using the same stack that they're going to deploy to for production use, and who therefore never use the runserver at all... Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this 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-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
On Sun, 2013-05-12 at 11:03 -0700, Jason Reethisma wrote: > @Russell > > "can't compel anyone to do anything"... you can compel people to NOT do > something, such as, "don't close a ticket as won't-fix without giving a > detailed explanation of why it should be closed". > > Saying that people cannot be compelled is an excuse to not take action. > > Ignoring the 3 outlined problems in the post you replied to while pretending > to ask for suggestions from the community is just a form of equivocation. > Politicians do it all the time... > As someone who uses Django, and lurks (mostly) on this list, I have to say that I think you have got completely the wrong end of the stick. The tone of your mail is not constructive, and is provoking a negative reaction even in me (and I am not one who has been putting massive amounts of time into building Django, keeping the tracker in order, and trying to keep the community running smoothly). I don't want to think about how such posts must make the likes of Russell, Jacob & co react - I can only say that in the years I've been here they've done a superb job keeping the frustration in check. This community, to me, is notable for the professional and courteous manner in which people making demands are directed toward what they need to do to have a chance of getting what they want. I'm not saying it's perfect, but it deserves rather more credit than you appear to be giving. If there is little to no chance that a particular feature will be implemented, it seems to me that is better for all concerned to close down the discussion fairly sharplish - the submitter then doesn't waste time thinking they're going to get something done about it, and the developers don't waste time explaining again and again and again why the submitter's latest rehash of the same argument is not going to make any difference (submitter wrong, bad fit for Django, philosophical issues, whatever - some people just don't seem to get the message). I suggest you take Russell's post at face value, by the way. "Looking for a positive outcome". Well, perhaps face value plus a head of frustration that he's hiding fairly well. Thanks again to all of you who are making it happen. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this 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-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)
On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote: > Hi Nick, > > On 02/19/2013 03:32 PM, Nick Phillips wrote: > > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I > > do, it seems rather problematic. In particular, that host verification > > is apparently turned off while DEBUG is True or while testing. > > > > Surely this makes it impossible to test, and makes it likely that > > misconfigurations will not be picked up until deployed to a production > > environment. > > > > Given that most setups require some customisation of settings for > > dev/staging/production/whatever environments anyway, why not leave the > > verification on at all times and allow us to ensure we get the right > > hosts in the right environments? > > There was extensive back-and-forth discussion of this in writing the > patch. The issue is that in almost all cases the correct value of the > setting in local development and under test are different from the > correct value in production. So how much value is there in knowing the > tests pass, and/or it works locally? That doesn't really increase the > chances that you have it configured correctly in production. It would at least ensure that you were aware of it and had attempted to set it... > In the end, > our estimation was that requiring it to be configured in local dev and > testing would introduce quite a lot of hassle (and potentially a major > roadblock for new users), with very little gain to offset that. What would the implications of having "localhost" in there be? > Note that it isn't impossible to test, if you want to; the check is > "disabled" under test by means of setting ALLOWED_HOSTS to ['*'] for the > duration of the test run, so if you want tests to exercise validation > you can just use the override_settings decorator to temporarily change > it for a test method or test case. Ah, thanks - I was at least missing that. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz Faculty of Medicine, University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this 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-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)
On Tue, 2013-02-19 at 14:50 -0600, James Bennett wrote: > We've issued several security releases today. Details are in the blog post: > > https://www.djangoproject.com/weblog/2013/feb/19/security/ > > We recommend everyone carefully read this one, as it has an > end-user-visible change requiring action beyond simply upgrading your > Django package. > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I do, it seems rather problematic. In particular, that host verification is apparently turned off while DEBUG is True or while testing. Surely this makes it impossible to test, and makes it likely that misconfigurations will not be picked up until deployed to a production environment. Given that most setups require some customisation of settings for dev/staging/production/whatever environments anyway, why not leave the verification on at all times and allow us to ensure we get the right hosts in the right environments? What am I missing? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this 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-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Possible bug in django oracle backend - no way to map from model type to oracle NUMBER type.
On Wed, 2012-10-17 at 12:16 -0600, Ian Kelly wrote: > > Do you know what type in model will map to NUMBER in oracle? > > There is none. The proper type would be a floating-point > DecimalField, but Django doesn't allow that as the decimal_places > attribute is required. I'm not really sure why that is; maybe the > requirement could be relaxed? > > If you don't need a lot of precision, then you could probably get away > with using a FloatField. Otherwise you might want consider creating a > custom field that looks like a FloatField but uses decimals instead of > floats. > Not if you have a "legacy" database which uses NUMBER, I'm guessing... I'd have thought the inability to work with any particular common field type should be a bug, as it could effectively prevent working with non-managed models altogether. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Revisiting multiline tags
On Fri, 2012-02-24 at 08:27 -0700, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/23/2012 11:29 PM, Russell Keith-Magee wrote: > > This thread contains 6 people expressing support for this change, and > > 2 against (a BDFL, a core developer) -- and you can add me to the -0 > > FWIW, I'd forgotten how painful the single-line restriction was the last > time I had to work on internationalized templates using blocktrans. The > presented use cases have me thoroughly convinced that this is an > unreasonable restriction on template authors, and I'd be +1 on lifting it. If the translation tags are pretty much the only things that would really benefit from multi-line tags (and they certainly seem to be the focus here), surely that's an indication that they're the problem, not the unavailability of multi-line tags? Do all the arguments really have to be within the single tag? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
On Mon, 2011-03-14 at 15:57 +, Tom Evans wrote: > This is one of my bug-bears with the current authentication system - > it has no concept of role. The current action when an identified user > visits the admin site is to display a login form, which is totally > wrong in my opinion. The user has already presented credentials, which > we have accepted, so why should we expect them to have another > different set of credentials? > > Similarly, most restricted access views are currently protected by the > login_required decorator. Again, this is pretty good, but it doesn't > solve the authorization issue. With the vast majority of views I > decorate with @login_required, I actually need three states: > > Unidentified -> login page > Identified, but no access -> homepage, with error message > Identified, access -> allow through Spot on, IMO - it's muddling authentication and authorization up together. The user is authenticated, and shouldn't be arbitrarily given the impression that they're not when they try to access a page to which they don't have access. There's nothing "special" about the admin here, except that it is provided as part of the "batteries included". How does your site respond when a user tried to access any other URL to which they are denied access? Whatever happens there is probably what should happen when they try to access the admin. It could be a 403, a redirect to homepage, a forced logout with disabling of account and email to admin, could be all sorts of things, depending on the site. The question should probably be "how can we allow the developer to specify the desired behaviour when the user attempts to access a URL to which they have no access?" - subject to the usual provision of sensible defaults etc. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #14733: A vote in favor of no validation of .raw() queries
On Fri, 2011-03-11 at 23:20 -0500, Jacob Kaplan-Moss wrote: > Hi Christophe -- > > Interesting; I didn't know about these constructs. > > I'm not opposed to this change, but I am a bit concerned about opening > up the ability to use raw() for stuff like UPDATE/DELETE where it'd be > a nasty code smell. I'd be interested in your thoughts on that: is > there a way we can prevent folks from shooting themselves in the foot > this way, or do you think trying itself is futile? If they're going to do it, they're going to do it - I can immediately think of several people who, on finding that they can't do what they want with raw(), would naturally progress to writing a postgres function to do the dirty work (on the grounds that that can then be called using "select"). Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Intermittent IOError exception raised and emailed to admins during file upload.
On Mon, 2011-02-14 at 11:10 -0800, Drew Volpe wrote: > Did you ever track down what was happening ? > > Was any more information discovered on this problem ? > > I'm seeing a similar issue in a eb service written in Django which > receives data from mobile apps as a POST. Not infrequently, I'm > seeing the same "IOError: request data read error" when I try to read > request.raw_post_data. It happens more than spotty connections would > explain. User double-clicks on submit button, second click killing the connection created by the first press and starting another one? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feedback required: #14799 -- Problem with setting up test databases
On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote: > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES -- > that allows the developer to explicitly encode the dependency between > databases. This means the developer can explicitly encode the > dependencies that exists in database creation order. We can default to > assuming 'everything depends on default' (which is what the current > trunk implements); but this gives end users the flexibility to define > any dependency they need. The patch on #14799 implements this solution > (although it needs some tests for the dependency resolution code and > documentation for the setting itself) > > My personal preference is for (4). I don't like the addition of a > setting, but it's a setting that most users will be able to ignore > (since there is a reasonably sensible default), and it is the most > explicit and configurable option available. > > Opinions? Alternatives? pre-syncdb handler to check that it's valid to actually run a syncdb on this database at this time? Seems a lot more general than just test-related, anyway; I'd have thought it would make more sense to see (and name, and document) it as a general dependency of one database on the other - so creation/updates/migrations should all always happen in an order which takes any defined dependencies into account. I'm guessing that the test setup just happens to be the only place (within Django itself) where any of these processes are automated across multiple DBs at the moment? FWIW I *always* forget that I have to explicitly call syncdb for each database, and expect the one call with no db specified to have done the lot. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: HMAC and timing based attacks - ticket #14445
On Tue, 2010-10-12 at 12:03 +0100, Luke Plant wrote: > The fixed strings are used to make the keys unique per application - see > below for what the keys are like that actually end up being used. I realise that, I just couldn't remember exactly why that was necessary... but you answered that below. > AFAICS the HMAC module does all this. From hmac: > > class HMAC: > """RFC 2104 HMAC class. Also complies with RFC 4231... > """ > # ... > > def __init__(self, key, msg=None, digestmod=None): > # ... > if len(key) > blocksize: > key = self.digest_cons(key).digest() > # ... > > So it is explicit - the hmac module does RFC 2104 for us, that's what we > are relying on it for. If this module *stops* doing this, then all the > existing MACs generated will be broken, so backwards compatibility means > it will carry on doing so. We should let this module do our crypto for > us as much as possible. Absolutely - I hadn't had a chance to check the hmac module, but given the fact that it does pre-hash or pad as recommended (and assuming it will continue to do so), that's fine. > Since we are effectively using > SHA1(different_fixed_string_for_each_application + SECRET_KEY) as the > key, it isn't obvious to me that using > SHA1(entirely_different_random_string_for_each_application) is really > any different, or really that much superior. Even if it was preferable > to use the latter, we can't do that easily with backwards compatibility > - we would need to generate new random strings for each key needed and > insert them into settings.py. Personally, I'd be looking for reassurance from a "crypto expert" at this point. I'd agree that it would appear that any problem is not obvious, but then neither would I expect it to be so. I would not be at all surprised if the combination of being able to control the message, and being able to get an HMAC of it with two different but related keys enables an attack, and some googling for "related key attack on hmac" would seem to support this possibility (although as I said, I'm no expert, and I don't have time to look into it in detail). > As for key rotating/refreshing - that would also (probably) be > desirable, but it would be significantly more work. There is no way to > change the key without invalidating existing HMACs (that's the whole > point), so you would effectively have something like a list of > SECRET_KEYS, where the first is the one used for generating HMACs, but > each is tried for verifying them. We had some discussion about this > before. See the bottom of http://code.djangoproject.com/wiki/Signing Yes, that's the kind of thing I was thinking of. > However, I don't think we should delay this change for the sake of that > ideal. Makes sense. What you're doing is clearly an improvement, and one with no cost to the user involved in making the change, so... Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: HMAC and timing based attacks - ticket #14445
On Mon, 2010-10-11 at 23:38 +0100, Luke Plant wrote: > Hi all > > For a while this has been on my TODO list, but I've finally got round to > it: > > * Use HMAC where appropriate in Django > * Fix timing based attacks. Cool. I'd been wondering about this for a while. > - is the new method (using hmac.new etc.) actually correct and something > we are happy to stick with for a good while, to avoid having to do > this again quite soon? As far as I read it, I'm doing the same thing > as keyczar: > > http://code.google.com/p/keyczar/source/browse/trunk/python/src/keyczar/keys.py#300 > > (BTW, there are good reasons not to use keyczar - it would add a big > dependency; it doesn't actually provide an API that is flexible enough > for some of our use cases, like where we use a shortened HMAC to make a > small URL; and it provides very little other value as a wrapper around > hmac). First of all I should say that I'm no crypto expert, but I'm worried about the key. Inclusion of fixed strings in a key for this type of use rings alarm bells, as does the use of an ASCII key (albeit 50 chars rather than the 20 recommended for use with SHA1 in HMAC), and the fact that in reality, it's never going to get refreshed. On the key strength, I notice that RFC2104 recommends the hashing of the key using the underlying hash function if the supplied key length is greater than the hash output length. It would appear that this will usually be the case, so Python's hmac module will probably be doing this for us. However, there's rather a lot of "implicit" and "probably" in that. And it would be perfectly possible that someone would update the hash function used at some later date without realising the assumptions that are being made. Might it not at least be a better idea to explicitly ensure that the combination of fixed string and SECRET_KEY is longer than the hash output length, and to hash the resulting string before calling hmac.new? I do seem to remember there being apparently good reasons for not using the same secret key throughout, although I can't remember what they were. Given the need for distinct keys for different purposes (I'm assuming there really is still such a need, for now), it seems to me that explicitly having separate keys in settings.py for each purpose would be preferable (either as separate entries or by chopping a much longer SECRET_KEY into substrings). That then makes me wonder whether there's any real benefit to storing the key in settings anyway - perhaps we could come up with an alternative that would both manage separate keys for each requirement, and actually allow the keys to be refreshed without invalidating existing otherwise-valid HMACs? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12012 Logging: request for comments
On Wed, 2010-09-29 at 09:00 +0800, Russell Keith-Magee wrote: > These all strike me as messages appropriate for a warning -- they're > all slightly concerning indications that you're either under some sort > of attack, or at the very least that your users are having a bad > experience on your site. > > This includes 404 -- manually entered URLs and annoying PHP hackbots > notwithstanding, your site shouldn't be generating 404s. If it is, you > should be investigating. The only argument I can see for 404 as an > INFO message is the prevalence; given that a 404 is often generated > without being a concern, it makes sense to make them easy to filter > out. However, IMHO, unilaterally ignoring 404s would be just as bad as > having too many. On top of that, any halfway decent log analysis tool > can filter these messages on a per-status code or per-URL basis. FWIW I agree with everything you say up to this point - it's just the conclusion that I differ on; I'd prefer to have the ability to use the logging config to send the 404s somewhere else. Not to ignore them, just to be able to deal with them separately as simply as possible. Since their issue is buried within the framework and can't easily be overridden, I think their ubiquity does justify the the lower priority. However, as Alex pointed out, this is essentially bikeshedding. So, since you're the one doing the work, at this point I'll shut up and wish you well with it :-) Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12012 Logging: request for comments
On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote: > So - have at it. I'm really excited by this; so let me know everywhere > I've messed up so that we can get this into trunk. Sorry, missed this before. A couple of comments... Logging config as last stage of settings loading is where is seems to have ended up in our apps at the moment anyway; I'd agree with whoever it was who said that it should be made possible/simple to force the config to happen earlier in settings (and then not happen twice), as depending on the complexity of the settings, it may be necessary to log from it. I'm worried by the use of "warning" for all 4xx statuses. I think it still makes sense to use the "original" syslog level definitions[*] as a guide, and on there I'd suggest that some 4xx statuses would merit "Info", some "Notice", and maybe one or two "Warning". "Notice" not being included in Python's default logging, I guess that means I'd split them between "Info" and "Warning". My view is that the main use of these logs to me is to help me see when someone is doing Bad Things (or trying to) to my system. I would be wanting anything that indicated a targeted exploration of my server to show up as "Warning", and anything that's most likely a random script kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many hits looking for e.g. poorly-configured phpmyadmin installations, that 404s would swamp anything that I really needed to be looking at. [*] Which are, according to 'man syslog' on this box: LOG_EMERG system is unusable LOG_ALERT action must be taken immediately LOG_CRIT critical conditions LOG_ERRerror conditions LOG_WARNINGwarning conditions LOG_NOTICE normal, but significant, condition LOG_INFO informational message LOG_DEBUG debug-level message Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote: > What exactly is your use case for something that designers want to > customize in the raw widget that widget.render() doesn't expose? That reminds me of one thing I'd very much like to see in any refactoring of form/widget handling. I'd like to be able to get at the "rendered" data (I say rendered, what I suppose I really mean is "transformed" either due to rendering needs or conversion from a graphical representation in the widget to something that could be resubmitted), without any of the surrounding chrome. There are various cases in which this can be useful, the most obvious of which is to tell whether the data in the form has been edited before submission. It's currently not possible to work this out from the "before" and "after" data, as you don't know how any particular field's data might have been munged by the widget (e.g. how is empty data rendered, any forcing to unicode, Python boolean to textual representation, date format transformation etc.). This would make solving problems like those in #11303 simple. As another example, changeset 10757 is heading down this path to fix #10288 in adding the _format_value method. I'd suggest that this be generalised and applied to all widgets (and the _format_value or whatever you want to call it to lose the "_" and be documented as part of the widget API). In one project here, I've had to write "duplicate" versions of all widgets to add a "disable" method and enable them to disable themselves in the UI while still submitting data (actually I'd like the standard widgets to support this too, but... ;-) ); while doing so I took the opportunity to refactor slightly more and ensure that all munging of data took place in one method which could then be used for the purpose described above - which worked just fine. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
On Sat, 2010-04-17 at 14:23 -0700, orokusaki wrote:
> 4) The attitude projected at developers gives the idea that Django is
> for the core team only, and that users are graced with the ability to
> use Django. While the contribution is much appreciated, the attitude
> is harmful to the core team and to the user base.
You might like to consider the fact that this is not at all the
"attitude" I see.
What I see is a group of people working very hard and holding themselves
to very high standards. In such a situation I would expect that I too
would have to meet those standards were I to wish any contribution I
might make to be included in their work ("work" in the sense of "a
work").
That is a challenge I would love to have the time for, but I don't. So
where I find that Django either has issues or fails to meet my needs, I
work around the problems in other ways. I might well file a ticket here
and there, and even a patch if I have one that might be useful, but
"inclusion straight into trunk" is not the only way a patch can be
useful. I'm certainly not going to try to tell them that they should be
doing things my way - and if I did want to, I wouldn't expect to get
anywhere with your current tactic.
This thread is distracting energy that could be better spent, so I'm
going to leave it at that, and would suggest that others do too.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: append_slash alternative: remove_slash
Graham Dumpleton wrote: > I was only commenting in relation to how Apache works and the > conjecture that: > > Yep, I assumed so - just wanted to make sure that nobody read it in a more general way. > Take it as you will as being irrelevant to the main conversation about > Django itself, but am just clarifying what is reality for Apache in > relation to that sweeping statement about what happened back in the > """days when all web pages were a collection of static html files""". > For users, the original statement ( /foo, /foo/ and /foo/index.html usually being equivalent ) was correct. I think you're probably just looking at it from a different angle. As someone else pointed out, it's very likely moot at this point anyway. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Graham Dumpleton wrote: >>> It's better to see it this way: Every page is an individual piece of >>> content for itself, and still every page can have subpages. >>> >>> A directory, on the other hand, can have subpages, but is not that >>> interesting for itself. Which we don't want to happen - we want all >>> our pages to be interesting! >>> >> Think back to the days when all web pages were a collection of static >> html files. Every directory within the server root had an index page >> (usually index.html). That page could be found at any of the three >> urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. >> > > My understanding is that the default behaviour of Apache has always > been that when '/path/to/dir' was used, it would redirect the client > to '/path/to/dir/'. > > It only became possible to override this from Apache 2.0 onwards. See: > > http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryslash > > Disabling need for trailing slash in Apache apparently has some > security implications as documented in that page and so in some > respects it is discouraged. > Two points: 1) Slashes were only added to directories; we're not talking about directories in this case; 2) Since we're not talking about that situation (i.e. a request for a directory, which could be handled by generating an index in one of two different ways), there are absolutely no security implications involved in the decision (or lack of decision ;-) ) that is currently being discussed. FWIW, I personally dislike extraneous slashes. Django views seem to me to be analogous to files, not directories, so I don't like seeing URLs that make them look like directories. Analogies can of course be taken too far. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Status of magic-removal
On 22/02/2006, at 12:34 PM, Luke Plant wrote: > > For now, if you have deadlines then trunk is the way to go (yep, bad > timing for that advice, sorry). While migration will be a bit of a > pain and tedious, it will at least be reasonably straightforward. > > Sorry for the difficulties you've had, Oh, no need to apologise. Besides, I'm not overly bothered -- challenges are fun, right? -- but I did think it was worth agreeing vigourously with Jacob, just to make sure you're all aware of the situation that new users find themselves in round about now. And thanks for everything so far; it looks like this could be quite enjoyable :-) Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Status of magic-removal
On 22/02/2006, at 10:58 AM, Jacob Kaplan-Moss wrote: > > I, for one, want to get m-r wrapped up and merged back to trunk as > soon as humanely possible. I feel like it's starting to be a drag on > new users trying to figure out why development on trunk seems to have > stopped, and I want to get us all back to one codebase. As a new user, I have to say that this is a little off-putting. The thought process went something like this: "Hmmm... so what's this magic-removal thing?" "OK, I see. So do we use magic-removal or 'normal' Django?" "This magic-removal thing sounds like it might be a bit dangerously experimental..." "But hell, look how much we're going to have to change if we stick with trunk for now. And we'll just be getting into all sorts of habits that will suddenly become obsolete just as we're getting the hang of it." "How about the documentation? Hmmm... well, I think we can handle keeping track of the changes while we learn." time passes, tutorial is followed, minor bug in MySQL code is found + fixed... "Bugger. NameError at /admin/foo/bar/person/1/delete/ global name 'ObjectDoesNotExist' is not defined. What have I let myself in for here? I mean, does anyone actually *run* this magic- removal stuff?" If it weren't for the fact that I need to get this running pronto, I'd be holding off and waiting for magic-removal to stabilise. Knowing what I do now, I don't know whether I'd use magic-removal -- damned if I do, damned if I don't. So yes, you're absolutely right. And my timing is, as usual, awful. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
