Re: Better input validation (was Proposal: default escaping)
I've been following this thread since the get-go with interest, but am a first time commenter here. Although I think the devs have a clear picture, I get the feeling that some participants in this discussion are geting input validation and output escaping confused which is generating lots of unnessesary discussion. Let me use an oversimplified example to explain. Let's suppose a user submits the following text to your app: 1 < 2 & 2 > 3 Now, that obviously is not html and as far as I can tell will not create any obvious security problems, so assuming you have good validators, that text should then pass validation and be written to the db as is. Some are suggesting that this text should be escaped before being written to the db. It is true that the above text should be rendered as follows in html/xml documents: 1 < 2 & 2 > 3 However, this is where the problem arises. Suppose one needs to output the text to a plain text file (such an an email or csv file)? If the escaped text is in the db, it then would have to be 'unescaped' in those cases. That is why escaping must remain in the template, and only the template author will know if some data needs to be escaped in that particular case (regardless of his (lack of) understanding of XSS). I don't mean to undermine data validation. That is very important as well and should never be overlooked. It's just that validation may not be the end all solution that some make it out to be. I understand that good/better validation is coming/in the works, but this thread is about escaping. I suppose escaping could be effected by how validation is implemented but that brings up the chicken-egg question which I won't ask. It seems to me the real question is whether escaping should be on or off by default and which would be more/less annoying. I think I'm with Simon on this when he says he would have to try it both ways to see which works best. Until then, I'll keep manually escaping things in the template. One more thing: regardless of whether escaping is on or off by default, having the block tags to turn it on or off for an entire template (or part of one) as well as raw and escape filters for individual variables would be very handy and can certainly be implimented before the 'default behavior' descision is made. --~--~-~--~~~---~--~~ 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: Better input validation (was Proposal: default escaping)
Michael Radziej wrote: [snip] > > I assume this is about Jacob's proposal, and it's handling this > case correctly. Let's go through the steps he specified: > [snip] Whether it is handling this case correctly or not, it still needs to be escaped in an html or xml template, but not in a plain text document. Therefore, we still need the option of escaping (or not) at the template level regardless of any validation in place, which was the point I was trying to make. However, it appears that someone has now changed the subject to 'validation' from 'escaping'... --~--~-~--~~~---~--~~ 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: Better input validation (was Proposal: default escaping)
James Bennett wrote: > On 6/22/06, waylan <[EMAIL PROTECTED]> wrote: > > Some are suggesting that this text should be escaped before being > > written to the db. It is true that the above text should be rendered as > > follows in html/xml documents: > > I don't think we should escape before storing. I think we should > *validate* before storing. In other words, we do everything we can to > make sure that the data going into the db looks like it's supposed to > look. > > Then on output you don't have to worry about it having been magically > pre-escaped somewhere along the line. You just escape if it's > something that you think needs escaping (again, don't have a single > point of failure -- validate the input *and* escape the output if > you've got a field that should never contain HTML), and get on with > life. > Uh, I thought that was the point I was making, or was I not clear enough? --~--~-~--~~~---~--~~ 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: posibility of generalize AdminMediaHandler ?
Karen Tracey wrote: > > If what works for admin can't/shouldn't/won't be generalized, then > maybe some documentation enhancements would help out people like me. See the page "How to serve static files"[1] in the docs. Then, be sure to read "The big, fat disclaimer" on that page. That should answer your questions for you. I would imagine the reason the ticket was marked won't fix is because there is already a mechanism in place to do this. [1] http://www.djangoproject.com/documentation/static_files/ --~--~-~--~~~---~--~~ 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: Newforms styling suggestion
I started to write a patch for this and have a few questions. First, I was adding the classes 'error' and 'required'. I think those are appropriate names. If anyone feels different speak now. I am adding the class to the , , and elements for each field as that seems to be the general consensus. I realize that some may wish to either override or create their own as_methods in a subclass etc. In so doing they may want to include their own html classes assigned to every field. If the as_methods take this into account, then the way I currently have it, every field which is not required and without errors will get which is not very clean. As an alternative I could build the entire class definition and only add it on error or required, but then we loose the ability to include other classes on subclassing. To work around the above problem, I could have _html_output() take another argument allowing a list of html classes to be passed in. Seeing we are already up to 5, that might be a little much. What do you think? Or are people not writing their own as_methods, making this a moot point. On Feb 16, 8:47 am, "Ceph" <[EMAIL PROTECTED]> wrote: > If an "error" class is going to be added, we might as well take the > leap and add a "required" class, too. > > On Feb 15, 7:12 pm, "Brian Morton" <[EMAIL PROTECTED]> wrote: > > > I don't know if this has been suggested yet, but has anyone considered an > > enhancement to newforms to optionally allow a field to have a different > > class if it has an error? It would be helpful for things like making error > > fields highlighted red, etc. Just a thought. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Newforms styling suggestion
FYI: I opened a ticket (#3512) and uploaded three separate patches. Personally, after working out all three, I think I prefer the third one. If we get some consensus on that, I'll see if I can find the time to address tests and docs, of if anyone else gets to it first... http://code.djangoproject.com/ticket/3512 On Feb 16, 2:38 pm, "waylan" <[EMAIL PROTECTED]> wrote: > I started to write a patch for this and have a few questions. First, I > was adding the classes 'error' and 'required'. I think those are > appropriate names. If anyone feels different speak now. > > I am adding the class to the , , and elements for each > field as that seems to be the general consensus. I realize that some > may wish to either override or create their own as_methods in a > subclass etc. In so doing they may want to include their own html > classes assigned to every field. If the as_methods take this into > account, then the way I currently have it, every field which is not > required and without errors will get which is not very > clean. As an alternative I could build the entire class definition and > only add it on error or required, but then we loose the ability to > include other classes on subclassing. > > To work around the above problem, I could have _html_output() take > another argument allowing a list of html classes to be passed in. > Seeing we are already up to 5, that might be a little much. What do > you think? Or are people not writing their own as_methods, making this > a moot point. > > On Feb 16, 8:47 am, "Ceph" <[EMAIL PROTECTED]> wrote: > > > If an "error" class is going to be added, we might as well take the > > leap and add a "required" class, too. > > > On Feb 15, 7:12 pm, "Brian Morton" <[EMAIL PROTECTED]> wrote: > > > > I don't know if this has been suggested yet, but has anyone considered an > > > enhancement to newforms to optionally allow a field to have a different > > > class if it has an error? It would be helpful for things like making > > > error > > > fields highlighted red, etc. Just a thought. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Newforms styling suggestion
On Feb 16, 3:28 pm, "jfagnani" <[EMAIL PROTECTED]> wrote:
> (I think I lost an earlier reply, so hopefully this isn't a dupe)
>
> I think it's important to add the classes to the fields themselves, as
> well as the , , and elements.
IMHO that addes no additional value. If you want the styling to apply
to the field itself, just do for example:
.error input {border:solid 1px red;}
>
> For complex, non-linear forms, I place fields in the template via
> {{ form.field }}, not with the as_ methods. I think the field styling
> is even more import in this case, because there's usually no room for
> inline error messages. I'd like to print the error messages above the
> form, and just highlight the fields.
>
> It'd also be nice if fields had an 'error' property, so that you could
> do some things in the template like {% if field.error %}
I haven't used newforms this way yet (I've only used as_methods), so I
assumed that was already possable from the template. If not, that is
another issue. IMHO, this should be the only way (in the template) you
could add classes directly to the fields themselves. If you want
general usage, use the as_methods, if you want finer grained control,
use the templates to manualy build your forms.
>
> -Justin
>
> On Feb 16, 11:38 am, "waylan" <[EMAIL PROTECTED]> wrote:
>
> > I started to write a patch for this and have a few questions. First, I
> > was adding the classes 'error' and 'required'. I think those are
> > appropriate names. If anyone feels different speak now.
>
> > I am adding the class to the , , and elements for each
> > field as that seems to be the general consensus. I realize that some
> > may wish to either override or create their own as_methods in a
> > subclass etc. In so doing they may want to include their own html
> > classes assigned to every field. If the as_methods take this into
> > account, then the way I currently have it, every field which is not
> > required and without errors will get which is not very
> > clean. As an alternative I could build the entire class definition and
> > only add it on error or required, but then we loose the ability to
> > include other classes on subclassing.
>
> > To work around the above problem, I could have _html_output() take
> > another argument allowing a list of html classes to be passed in.
> > Seeing we are already up to 5, that might be a little much. What do
> > you think? Or are people not writing their own as_methods, making this
> > a moot point.
>
> > On Feb 16, 8:47 am, "Ceph" <[EMAIL PROTECTED]> wrote:
>
> > > If an "error" class is going to be added, we might as well take the
> > > leap and add a "required" class, too.
>
> > > On Feb 15, 7:12 pm, "Brian Morton" <[EMAIL PROTECTED]> wrote:
>
> > > > I don't know if this has been suggested yet, but has anyone considered
> > > > an
> > > > enhancement to newforms to optionally allow a field to have a different
> > > > class if it has an error? It would be helpful for things like making
> > > > error
> > > > fields highlighted red, etc. Just a thought.
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: #20824 - Email-based auth contrib module; some help required
On Thursday, February 27, 2014 6:50:38 PM UTC-5, Camilo Torres wrote: > > normalize_email will indeed allow both us...@example.com and > us...@example.com to be different entities. From the user > perspective, this is an error. Most probably the user enters some day their > email in all upper case because he pressed the CapsLock key, or copy pasted > a transcript of his email, etc., the user could not be able to figure out > the difference and simply could not log in. > How about a more common real world situation -- on mobile devises? They will often "helpfully" assume the first letter of the first word in a field should be uppercase and do so for you. You have to be paying attention and specifically tap the shift key before typing to turn it off, then type your email address. This is an annoyance of mine because native UIs will often recognize that you are typing in an email field and not do this (even giving you a custom keyboard with the @ symbol), but web pages will not. Perhaps on some devices does the right thing -- but in my experience it isn't consistent (based on general observations only). The point is that the user will inadvertently type u...@example.com on their mobile device after registering with u...@example.com on their desktop/laptop. And they won't understand why they can't log in if it is case sensitive. Given that both addresses will deliver email to the same email account, it seems to me that both should be valid for the same account as an email based username on a sign-in form. Waylan Limberg > Is preferable to think, in this case, in protecting the user from their > own mistake (from our perspective as programmers), and do as Atul > Bhouraskar says: transform the email data in a consistent way before > insert/update/search to the DB. > > On Wednesday, February 26, 2014 8:31:40 PM UTC-4:30, Atul Bhouraskar wrote: >> >> Won't normalize_email will allow two distinct users us...@example.comand >> us...@example.com to be created? Case insensitive searches will return >> multiple users for a 'get'. >> >> Perhaps the closest we can get is to ensure that any user created using >> Django functions is saved with a consistent case transformation and then >> perform an *exact* search after applying the same transformation to the >> input? >> >> One idea could be to add a 'transform_email' or similar hook that by >> default calls normalize_email and ensure that it is applied both to data >> that is about to be saved and to search terms. Projects that wish to change >> the behaviour can simply override transform_email to perform for example >> lowercase conversion if so desired. >> >> Atul >> >> >> On 27 February 2014 11:43, Russell Keith-Magee wrote: >> >>> >>> On Thu, Feb 27, 2014 at 8:31 AM, Curtis Maloney < >>> cur...@acommoncreative.com> wrote: >>> >>>> Doesn't the UserManager already have a "normalize_email" method which >>>> lower-cases the domain and leaves the mailbox name alone? >>>> >>>> IMHO It's "proper" to leave it this way by default, and probably >>>> mention in the docs it's used so if you want to change it, that's the hook. >>>> >>> >>> It does - assuming you use User.objects.create_user() to create all >>> your users. However, the UserCreationForm doesn't use this (and hasn't ever >>> used this); it also doesn't account for fixtures, or any other path into >>> the database that might exist. >>> >>> So - while normalising case is probably a good idea, and should probably >>> be added to the Create/Update User form, the searches will still need to be >>> case insensitive. >>> >>> Yours, >>> Russ Magee %-) >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/CAJxq84_1%2B_oVDUAeHyXoFGTirsZEgejaY6q4hNK0EZGpqS96Wg%40mail.gmail.com >>> . >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/30f6abcc-d1fc-417d-aa44-aa5b519bdc54%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
1.2 Proposal: Finish contrib.comments Moderation
Currently, contrib.comments has a very useful (and customizable) mechanism for putting questionable comments into moderation. However, approving/ rejecting comments afterword is still unfinished. There is a set of urls/views/templates which provide a decent way to do this, but it is currently undocumented and therefore (as I understand it) still subject to change. There are a number of different ways this could be addressed: 1. Document the existing code currently available. Pros: May potentially work without admin app (untested by myself). Cons: Requires way too much setup by the user IMO and although the templates look like admin pages, the urls clearly indicate that it is not part of the admin. 2. Implement ticket #11625 -- Add admin actions to the comments admin. Pros: Simple - least amount of work. Cons: Getting a list of comments in moderation is unintuitive (requires user to select the "is_public==False" list filter on the admin page). 3. Using a proxy model and custom manager, create a second admin instance which only lists comments in moderation and offer the same admin actions as in 2 above. Pros: Simple and more intuitive for the end user. Cons: Moderation is on a separate admin page. I haven't actually tested that this works. 4. Incorporate the existing views into the admin by extending the base get_urls() method to point to them. Pros: Uses the existing Code. The new views will actually use admin urls. The views could potentially still be used outside an admin app. Cons: Will require some way (custom templates perhaps) to include links to the new admin views. Interestingly, options 2, 3, & 4 all rely on new features added in 1.1, which may explain why they were not implemented before now. Personally, I'm in favor of 2 (it is my ticket and patch), although 3 may be a nice addition which could always be added later. That said, I do see the attractiveness of 4, although I am unsure of the amout of code we can reuse or the amount of work involved in that option. Any input on these? The other piece that is missing IMO is a way to make those admin actions available on an individual comment. Some times, one actually needs to read the comment to know if it is spam or not. But, reading the comment, then going back to the list view, selecting the appropriate comment from the list and then selecting the admin action seems like a little much. True, the user could set `is_removed` to `True` and save or delete the comment, but then the appropriate moderation signal is never sent and any custom (perhaps trainable) moderation system has no way of getting feedback. Of course, there is no way of doing this last bit now with the existing undocumented code, and it should probably be a separate proposal for a general admin feature, but I included it here in relation to comments for completeness sake. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: 1.2 Proposal: Finish contrib.comments Moderation
Sigh! I guess I sent this out a little prematurely. On Wed, Aug 12, 2009 at 3:50 PM, Waylan Limberg wrote: [snip] > > 2. Implement ticket #11625 -- Add admin actions to the comments admin. > [snip] > > 3. Using a proxy model and custom manager, create a second admin > instance which only lists comments in moderation and offer the > same admin actions as in 2 above. > [snip] > > 4. Incorporate the existing views into the admin by extending the > base get_urls() method to point to them. > [snip] > > The other piece that is missing IMO is a way to make those admin actions > available on an individual comment. Some times, one actually needs to > read the comment to know if it is spam or not. [snip] Actually, implementing option 4 would accomplish this. The fact is, the existing (undocumented) list view is not needed in the admin as option 2 or 3 would fill that need. Therefore, the only views that we would need to map to admin urls would be the `approve` and `remove` views. We just need a custom template for the add/change view which adds the respective buttons next to delete, save, etc. The common code between the admin actions and the approve & remove views could be factored out into a couple utility functions which, along with the proxy model with custom manager (from option 2) would provide enough for some one to implement there own non-admin solution. That is, if that is even a goal. So, the question is, whether we go with option 2 or 3 (and add option 4), do we want to remove the existing undocumented views and templates for listing and acting on the moderation queue? Or do we want to leave them in (and undocumented) as an example of how it could be done? Of course, I'm assuming we are not concerned about backward compatibility as none of this has yet to be documented. However, if might be nice to depreciate it first for those who dug into the code and are using it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Suggestion: Better way to extend user table
On Thu, Aug 20, 2009 at 9:22 AM, Rob Hudson wrote: > > Take a look at ticket 3011: > http://code.djangoproject.com/ticket/3011 > I don't know, but that seems a little too "magic" for me. The User model appears to be imported from somewhere else than it actually is. Isn't this what the core devs don't want to do? Anyway, you do realize there is already a set precedence in Django for how to do this sort of thing. See custom comments [1] and get_model(). It seems more likely something like that would actually get in. [1]: http://docs.djangoproject.com/en/dev/ref/contrib/comments/custom/#django.contrib.comments.get_model -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Replacing get_absolute_url, I am against it
On Thu, Sep 10, 2009 at 11:23 AM, drozzy wrote: > > Just read the "Replacing get_absolute_url proposal": > http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl > > and personally I think adding two functions get_url_path and get_url > is a lot more confusing. One can never remember which one gets the > Absolute url and which one gets the Relative url. Easy, get_url returns the entire url while get_url_path returns only the "path" portion of a url. One could imagine feature creep resulting in 'get_url_protocol', 'get_url_domain' etc. I wouldn't actually recommend those be added, but by thinking about it that way, it trains my brain how to parse the proposed function names. > If it is going to be done I propose adding another function, and thus > have two possible functions on the model: > get_relative_url > get_absolute_url That seems like the obvious solution except that get_absolute_url currently returns a url path. Oops! With the change, everyone's existing code will suddenly break. The only way to fix it is to depreciate get_absolute_url and create new names for the replacements. Oh, and this reference to relative urls. Relative to what? The site root? The app root? The currently viewed page? "get_relative_url" is probably not what you actually want. "get_url_path" is. Of course, this all really a bikeshed issue. Generally, 'he who builds the shed gets to paint it.' -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: What is the status of auto_now and auto_now_add?
Well, both auto_now and auto_now_add are fully documented [1] and part of the official releases since 1.0. And I note that the docs specifically mention how auto_now_add behaves in the admin (remember the newforms-admin was merged before 1.0 was released). That being the case the devs have committed to long term support. At least, as I understand it, if they were to be removed it would happen only after depreciation warnings etc through multiple releases before they would be dropped completely. Of course, I can't speak for what the core dev's official opinion is of them, but they are all in the middle of DjangoCon this week and generally not checking their email. Thus the quiet on the lists. You'll have to wait a few days for more. Regardless, I think you may be dwelling on some old, outdated info. [1]: http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.DateField -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 4:36 AM, Vinay Sajip wrote:
>
>
>
> On Sep 17, 9:25 am, Simon Willison wrote:
>> Problems and challenges
>> ===
>>
>> 1. The Python logging module isn't very nicely designed - its Java
>> heritage shines through, and things like logging.basicConfig behave in
>> unintuitive ways (if you call basicConfig twice the second call fails
>> silently but has no effect). This is why I suggest wrapping it in our
>> own higher level interface.
>
> Simon, I'm the author of Python's logging package. Sorry for the delay
> in replying, I've been away from this list awhile. I think the "Java
> heritage shines through" is just FUD. basicConfig's behaviour is fully
> documented here:
>
> http://docs.python.org/library/logging.html#logging.basicConfig
>
> Including the fact that it sometimes (by design) has no effect.
>
> There are a lot of people for whom logging just means writing to a
> file, and that's why they have difficulty understanding why logging is
> designed as it is. I would suggest you take a quick look at
>
> http://plumberjack.blogspot.com/2009/09/python-logging-101.html
>
> and then tell me why you think Python logging isn't well designed for
> its purpose. You can do basic logging with two lines of setup (one
> line if you ignore the import):
>
> import logging
> logging.basicConfig(level=logging.DEBUG,filename='/path/to/my/log',
> format='%(asctime)s %(message)s')
>
> and then
>
> logging.getLogger(__name__).debug("Just checking this works")
>
> Not too sure where the Java heritage is there, or where the hard part
> is.
>
The hard part is that basicConfig only works like that back to Python
2.4 yet Django supports 2.3. When I added logging to Python-Markdown,
this was the hardest part. Figuring out how to configure logging so
that it works in 2.3 as well. The documentation is not exactly helpful
in that regard.
In fact, it was for this very reason that we added our own wrapper
around logging. It didn't seem reasonable for our users to go through
the same pain that we did. Sure we got a few things wrong at first,
but with the help of a few people in the community we worked those out
and our wrapper seems to work ok now. Yes - ok - I get the sense it
could be better.
Ever since then, any mention of logging leaves a bad taste in my
mouth. Perhaps if I was working only in 2.6 or such, this wouldn't be
an issue, but we have promised support back to 2.3.
Of course, it is possible that I'm missing something obvious.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
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: Adding an option to re-test only failed tests
On Tue, Sep 29, 2009 at 1:58 PM, Simon Willison wrote: > > On Sep 29, 5:03 pm, Rob Madole wrote: >> I've been using nose for our tests, and one of the features that I >> really like is the ability to run the tests again but filter only the >> ones that caused a problem. >> >> I'm thinking it would look something like this >> >> ./manage.py test --failed >> >> Does this sound worthwhile to anybody? > > I don't understand how this works - does it persist some indication of > which tests failed somewhere? If so, where? > My recollection is yes, nose persists which tests passed/failed for the previous run, but I don't recall where. Personally, I've never used this (except to see how it works in nose) because I'm always concerned that while a recent change may fix a failing test, it could cause some other test to fail that previously passed. So I'm going to run the whole test suite anyway - or at least all the tests for that module, etc. Alex suggestion of --failfast seems like a much more useful way to shorten test runs. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 6:29 PM, Simon Willison wrote: > [snip] > > By default, runserver would display no log messages at all. Runserver currently outputs each request to the commandline. Any reason that couldn't be handled by a logger? I seem to recall people complaining that they couldn't redirect that output elsewhere before when logging discussions came up. [snip] > > My philosophy here is that log messages should be ignored unless > explicitly told otherwise. Django gets run in various different ways - > runserver, test and in deployment under mod_wsgi/FastCGI/etc - and > it's not at all obvious what the default log output behaviour should > be. As long as we make it extremely easy to see log messages if we > want them I think having them off by default makes sense. It also > ensures no surprises for people upgrading from 1.1 to 1.2. Yeah, this was an issue we ran into. People will deploy your code in all sorts of situations and you can't make any assumptions about what would constitute an appropriate handler. They have to define those themselves. Even management commands can be called from scripts and may need output to be logged someplace other than sdterr. > 4. Add a way to configure loggers in Django's settings.py file, in > particular for use in production. I'm not sure if these settings > should be ignored when running under other circumstances (./manage.py > test etc) in favour of the command line option, or if they should > still take effect. Well, a logger can have multiple handlers. I would think we would want to leave the handlers defined in settings.py in tact and add the manage.py handler (most likely output to stderr - but could be different - see my comment above). -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 the #6904 ticket (case insensitive sort in dictsort)
On Thu, Oct 15, 2009 at 7:44 AM, Douglas Soares de Andrade wrote: > > Hi all, > > What is the status of the following ticket ? > > http://code.djangoproject.com/ticket/6904 > Well, the "Triage Stage" is currently set at "Design decision needed" which means that it's waiting for a core dev to review the ticket and either accept or reject it. > I just had this issue in Django 1.1 and i totally agree with mathwizard > said. I don't - and I just posted a comment to the ticket explaining why. If you (or anyone) wants case-insensitive sorting, just create your own custom filter that does just that. You could even copy the built-in filter to your own project/app and use it with a one or two line change. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Bug in django\template\__init__.py ??
On Thu, Oct 29, 2009 at 10:37 AM, Johan wrote: > > I am > wanting to use the template engine outside the context of a django > project so I would not have a settings file anywhere on my path. This is documented here: http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-without-setting-django-settings-module > I am > assuming that the code works in a project context since the project > would import settings and this 'broken' import would just fail > silently Pay special attention to the last section (Either configure() or DJANGO_SETTINGS_MODULE is required) of the docs linked above. As Russell mentioned settings is lazy so you don't get an import error but you will get a RuntimeError if settings have not been configured properly when you actually try to use your templates. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Bug in django\template\__init__.py ??
On Thu, Oct 29, 2009 at 11:07 AM, Waylan Limberg wrote: > On Thu, Oct 29, 2009 at 10:37 AM, Johan wrote: >> >> I am >> wanting to use the template engine outside the context of a django >> project so I would not have a settings file anywhere on my path. > > This is documented here: > > http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-without-setting-django-settings-module > >> I am >> assuming that the code works in a project context since the project >> would import settings and this 'broken' import would just fail >> silently > > Pay special attention to the last section (Either configure() or > DJANGO_SETTINGS_MODULE is required) of the docs linked above. As > Russell mentioned settings is lazy so you don't get an import error > but you will get a RuntimeError if settings have not been configured > properly when you actually try to use your templates. Doh' sorry that is wrong. Actually you do get an ImportError - but not until the settings are actually accessed (being lazy and all). The RuntimeError is if you call settings.configure() more than once. Thus, the importance of reading that section carefully. :-D -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Enhanced debug output colors: django code is green, user code is red.
On Tue, Nov 3, 2009 at 10:57 AM, Tobias McNulty wrote: > On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov wrote: >> >> On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty >> wrote: >> > I'm not a big fan of the red/green either. They imply that Django code >> > is >> > "bad" and user code is "good". >> The opposite, in fact. >> Django code is green, "good", user code is red, "untrusted". > > Whoops, my bad. I still think there are concerns about the colors, however. > They imply that something is wrong with the red code, which might not be > the case. There is also the concern of whether or not these colors are > distinguishable to colorblind folks. I think what you need to try to do is > make the user code draw your attention first, and the Django code draw your > attention second. I don't think the current color scheme does that in an > effective way. > Tobias > Actually, they current colors look an awful lot like diffs as they are displayed by on various sites (green lines added, red lines removed). In fact, at first glance, that's what I thought I was looking at. One more reason to change the colors I suppose. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 1:38 AM, Tobias McNulty wrote: > Latest patch, including fail_silently, is up for review: > > http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff > Looking though this patch I couldn't help but notice the new get_messages function. What if a project has neither the MessageMiddleware nor the contrib.auth app enabled? Sure a reusable app could catch the error, but that error will change once all support for user.messages are removed in 1.4. Shouldn't the call to user.get_and_delete_messages be wrapped in a check that request.user exists like the new add_message function does? -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 10:23 AM, Luke Plant wrote: > On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > >> Looking though this patch I couldn't help but notice the new >> get_messages function. What if a project has neither the >> MessageMiddleware nor the contrib.auth app enabled? Sure a reusable >> app could catch the error, but that error will change once all >> support for user.messages are removed in 1.4. Shouldn't the call >> to user.get_and_delete_messages be wrapped in a check that >> request.user exists like the new add_message function does? > > It is - the inline 'get_user()' function does effectively just that: > Right. As Tobias pointed out, the get_and_delete_messages on AnonymousUser returns an empty list. That was the part I missed. Thanks for clearing that up. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: What do people think about the get_absolute_url proposal?
On Tue, Dec 15, 2009 at 3:23 PM, Michael Richardson wrote: > > > On Dec 15, 4:35 am, Ivan Sagalaev wrote: >> Mike Malone wrote: >> > Well, not really. It's making a way to generate a URL based on the >> > request object global. I agree that it's not ideal, but it's not the >> > same as just making the request object global. >> >> My main gripe is not globalness of a request object itself (I agree with >> "not ideal" here) but the very idea of constructing a URL from request. >> >> > You wouldn't have any trouble in a standalone script unless you tried >> > to call the get_absolute_url() function. >> >> But I kinda want that. Here's two more usecases where using current >> request for creating URLs is broken: >> [snip] > > With these cases (the former more so than the latter) you are creating > URLs for an entirely separate project, not your own, essentially. You > aren't creating URLs for that particular project, which is where a > request-aware URL creation resource is intensely useful. > > We pass around request objects all over the place in order to get this > functionality. request.build_absolute_uri is great, but it does > require that request object and passing it around - which sucks. > > I am 100% with Mike on this. > The way i see it (which may be wrong), this is not a proposal to make the request object global or replace/refactor the contrib.site app. In fact, some of the use cases mentioned strike me as things that would require overriding the default get_absolute_url method anyway. It seems to me like everyone is arguing over things outside the scope of this proposal. Sure, a better solution than the current site app would be nice, but that's not on the table right now. So given the existing framework, and knowing you can override the default very easily, is seems that Simon's proposal fits the bill. I was going to suggest that the method could accept a request object as an optional argument and fall back to using the site app if no request is provided. But if you have the request, you can get the domain yourself and call get_url on the model. Besides, I'm not really sure how that would translate to use from within the template system. But wouldn't that really come under a future proposal for a better/replacement site app? Or should the current proposal be set aside until that is solved first? Personally, I'd prefer this proposal to land now and hope for a better solution to the limitations of the site app later. That way the API is set and I can start using it. If the stuff behind the scenes changes later that's fine. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Changing the Backend for Error Emails
On Mon, Dec 21, 2009 at 3:25 PM, Mat Clayton wrote: > Hey all, > > Now that Email Backend's have landed, and we finally got round to rolling it > out in to production, I discovered small niggle with our deployment. > Currently we use an external email provider to deliver email, and the > backends has allowed us to do this fantastically. However when an error > occurs in our main site, which happens in production occasionally :( We very > rapidly eat up all our credits with error emails, one proposed solution > would be to be able to configure an independent backend for crash emails. > Having talked to a few startups using similar cloud technology this seems a > fairly common situation. > > As far as I can could spot, there is no way to isolate the production and > error emails, has anyone else tried this? Also is any chance this might get > into core, if we propose a patch? > I believe this may fall under the logging proposal [1] which has been approved for 1.2. Although, I don't know whether it will be ready or not. Regardless, I would think providing work on this would be the best way to get a solution into core. [1]: http://code.djangoproject.com/wiki/LoggingProposal -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Model validation incompatibility with existing Django idioms
I've only scanned the docs the other day and haven't actually used the
new model validation stuff, so my impressions may be a little off,
but...
On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans wrote:
> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison
> wrote:
>> A couple of related tickets filed today about model validation:
>>
>> http://code.djangoproject.com/ticket/12513
>> http://code.djangoproject.com/ticket/12521
>>
>> The first one describes the issue best - the new model validation code
>> breaks the following common Django convention:
>>
>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>> if form.is_valid():
>> p = form.save(commit=False)
>> p.user = request.user
>> p.primary_contact = somecontact
>> p.save()
>>
My initial reaction to this snippet was to wonder why the model was
not being validated after the additional data was added/altered.
Shouldn't you be doing:
form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
if form.is_valid():
p = form.save(commit=False)
p.user = request.user
p.primary_contact = somecontact
if p.full_validate():# <<<<< note this line
p.save()
[snip]
> Once again, that means ModelForm won't really validate your model,
> only your form. form.save() might still throw a database error just
> like before the merge. We can slap a big warning in the ModelForm docs
> though.
Well, that's why I expected the extra validation check on the model
itself. I understand the desire to have the ModelForm actually
validate the model and work in one step, but sometimes we need the
other way too (as you acknowledge).
> One (probably unhelpful) way to make ModelForm validate your whole
> model would be to add a Meta flag to ModelForm:
>
> class UserForm(ModelForm):
> class Meta:
> # Defaults to False
> validate_model = True
Well, what if one view uses that ModelForm one way and another view
uses the same ModelForm the other way? What about
``form.is_valid(validate_model=True)``?
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
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: Sessions: does set_expiry has a max value?
On Thu, Jan 14, 2010 at 10:50 AM, Pablo López wrote: > I *did* search in this group... not in others :-) > > Thank you anyway > Ah, well for future reference, django-dev is specifically for the development *of* django. For help with using django you should always go to django-users. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Django documentation for newer users
On Fri, Mar 5, 2010 at 11:35 AM, stherrien wrote: > What I'm suggesting is that we setup something to allow everyone to > improve the docs with help from the core django group. I think this > would be very helpful to everyone. if one of the core group would like > to help us get setup to do this it would be great. maybe if they setup > a repository with the current online docs online so we can add updates > as we do with django itself. So everyone else already answered your concern above, Anyway, regarding your first question, see the "Global Module Index". It contains full import paths to each module and links to the docs for that module wherever they may be (howtos, ref, etc). But yeah, the individual docs should probably include import paths as well. http://docs.djangoproject.com/en/1.1/modindex/ As far as general organization goes, the "Table of Contents" is more helpful imo. I see the front page as more of a highlight of interesting things intended for those taking their first look at the project, but the table of contents gives a much better overview of how everything is actually organized by document section etc. The urls even match the pattern used here, and the "next" and "previous" links follow the order of documents here. http://docs.djangoproject.com/en/1.1/contents/ Both are linked to from every doc page in the sidebar to the right (In the "Browse" section). > > On Mar 5, 11:20 am, stherrien wrote: >> Exactly my point docs need to be more organization to be constructive >> for django users. >> >> On Mar 5, 11:05 am, Jared Forsyth wrote: >> >> > To be honest I am quicker to just go to django's source code rather than >> > the >> > docs, as often I can find what I need there, and the docs aren't (imo) >> > organized enough to provide much of an advantage. >> >> > On Fri, Mar 5, 2010 at 8:46 AM, stherrien wrote: >> > > Hi all, >> >> > > I have a request that django documentation show the import locations >> > > for classes like in other well formed docs found on the web showing >> > > the users where the classes can be found for import. I think this >> > > would be handy for newer users and experienced users finding something >> > > new. Documentation on the site is different from page to page. Take >> > > for instance the file object doc page in django doesn't tell the user >> > > where this can be imported which requires you to dig into the python >> > > help pages to try and find it. which is "from django.core.files.base >> > > import File". it would be nice to show this consistently across the >> > > site. I would be happy to help make this happen. >> >> > > -shawn >> >> > > -- >> > > 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. > > -- > 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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Logging in Django
On Fri, May 28, 2010 at 4:39 PM, Mathieu Leduc-Hamel wrote: > Oh cool! next time I'll check in the PEP list before... > > But I don't understand how it'll work with older python version, like > the current 2.6 branch ? Vinay has already stated that he is making his code (which is part of python 2.7) available to be distributed with Django so it will work on any version that Django works on. > > On Fri, May 28, 2010 at 4:33 PM, Vinay Sajip wrote: >> >> On May 28, 9:16 pm, Mathieu Leduc-Hamel wrote: >>> I would say, why not use the default python way to config logging, >>> handler and loggers ? it work fine and many projects are using it. >>> That way, we'll be able to use the same logging configuration for our >>> django projects and the different python library that we may use and >>> we the logging is implemented using the default python way. >>> >>> I don't exactly understand why it should be in the settings.py file ? >>> >> >> What's proposed to be in settings.py is the actual configuration, not >> the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2 >> configuration via dictionaries (rather than via Python code or the ini- >> style confguration files - see PEP 391 for more details of the >> rationale behind dict-based configuration). >> >> Existing projects (like Django) can use the standalone dictconfig >> project on BitBucket to get the functionality which will be in Python >> 2.7 and 3.2, for use with earlier versions of Python. So really, >> Django is using the same mechanisms as Python for logging. It's good >> practice to put a shallow interface between the Django and Python >> logging configuration layers, to allow Django to specify sensible >> defaults. (There's an example of that in my Launchpad branch - the >> Django layer adds a default key in the dictionary to specify that by >> default, existing loggers are not disabled when configuration >> happens.) >> >> Logging of third-party libraries and django-apps (which make use of >> logging) in a Django site will be customisable through the logging >> configuration mechanism being proposed. All of Django, your apps and >> their dependencies, third-party apps and their dependencies - if any >> of them already use logging in the conventional way, you will be able >> to modify their logging behaviour through this mechanism. >> >> Regards, >> >> Vinay Sajip >> >> -- >> 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. >> >> > > -- > 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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: greater_than and less_than template filters
On 10/11/06, Le Roux Bodenstein <[EMAIL PROTECTED]> wrote: > > I wrote some filters On 10/12/06, Tim <[EMAIL PROTECTED]> wrote: > > Here are some simple math functions that we found useful for templates > as well: > Both of you should post those in the cookbook [1] on the wiki so they don't get lost in the archives here on the list. [1]: http://code.djangoproject.com/wiki/CookBookTemplateFilters --~--~-~--~~~---~--~~ 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: Potential bug in django.core.handlers.modpython ?
On 10/16/06, DavidA <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I noticed an inconsistency between the request META information in the
> modpython handler versus the base handler.
>
> I'm opening the URL http://web/data/pos/ which goes through two URL
> conf's:
>
> The default urls.py for the application:
> (r'^data/', include('pfweb.core.urls')),
>
> And the urls.py for the 'core' app:
> (r'^pos/$', 'pfweb.core.views.list_positions'),
>
> But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the
> development server its '/data/pos/' (which I think is right).
>
> I'm using the PATH_INFO as a base for my next/previous links so they
> aren't working in production (under apache).
>
> Shouldn't I be able to see the full path of the URL somehow under
> mod_python? (Maybe there is a better way than I'm trying).
>
> I'm not sure what's right so I thought I'd post a question here before
> submitting a ticket.
>
> Thanks,
> -Dave
My guess is the problem lies in your Apache settings. Post a copy of
your mod-python settings and we'll see what we come up with.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: capfirst and title template filters
On 11/16/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Gary Wilson wrote:
> > So why the special cases? Should we keep the filters consistent with
> > their str methods?
> > title -> str.title()
>
> I did realize an example where the title filter's implementation would
> be desired. When you've got a possessive noun:
>
> >>> Template("{{ text|title }}").render(Context({"text": "the boy's blob"}))
> "The Boy's Blob"
>
> as opposed to:
> >>> "the boy's blob".title()
> "The Boy'S Blob"
>
I think you just answered your own question here. It seems more likely
that "boy's" would need proper treatment than "de'errico" because the
name is more likely to already be properly capitalized when entered.
And with the current filters, as you point out, that proper
capitalization won't be altered. Hey, if someone types in their name
wrong, we shouldn't be expected to fix it, or even know how. 'Garbage
in, garbage out' (tm).
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: "getattr(): attribute name must be string"
On 11/30/06, James <[EMAIL PROTECTED]> wrote: > > Brian, splendid stuff :) Seems to work so far, at least in terms of > keeping database integrity and actually doing what it's supposed to. > Thanks very much for taking the time to post this solution. Tests or not, be sure to post the fixes to the ticket (and perhaps a link to this thread) so is doesn't get lost. > > Now how do I write a regression test? Any docs available? > > -- > James > > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Default representation of a Form
Brantley Harris wrote: > Maybe good practice, but not practical. I'd love to not have to use > tables. But practical CSS just isn't there yet. Yes, tables aren't > good for general layout, but they still have their uses, and forms are > a prime example. > A table's uses generally consist of representing tabular data. A form could arguably be considered tabular data in many cases, so a table could potentially be acceptable. That said, other alternatives certainly need to be considered, and made available. So count me +1 on adding Form.as_p() I'm +0 on making it the default. > On 11/30/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > >> I would say not using tables for layout may count as a good practice >> like encouraging clean URLs, proper distinction of GET and POST etc. >> > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Re: Default representation of a Form
Adrian, excellent job abstracting the common code into
`Form._html_output()`. Now, anyone can write there own `as_method()`
as a one-liner - with one minor problem...
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 12/1/06, James Bennett <[EMAIL PROTECTED]> wrote:
> > So maybe an as_dl() method needs to go in?
>
> With as_dl(), how would error messages be displayed?
I was going to suggest
label
error
field
But looking at the code, the error string is passed in first
regardless of whether `errors_on_separate_row` or not. Perhaps
`_html_output()` should use the optional mapping key for string
substitution [1]. So, for example:
- 93 output.append(normal_row % ((bf_errors, label, bf)))
+ 93 output.append(normal_row % ({ 'error' :
bf_errors, 'label' : label, 'field' : bf}))
Then
as_dl(self):
return
self._html_output(u'%(label)s\n%(error)s\n
%(field)s', u'?', '', False)
Hmm, not sure how the top_errors would display here. Maybe someone
else could enlighten us on that.
Anyway, by key mapping string substitution, that would greatly enhance
the flexibility IMHO. It would certainly make creating custom
`as_method()` functions easier/more flexible.
As an alternative, there is also Template strings [2], but key mapping
works fine and (I believe) was in python2.3 (or earlier) while
Template strings were introduced in python2.4.
[1]: http://www.python.org/doc/current/lib/typesseq-strings.html
[2]: http://docs.python.org/lib/node40.html
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? It's > simpler, it wouldn't require cookies and I can't immediately think of > any downsides to the approach. > Presumably each page would do validation on submit (we don't want to send the user back to page one after completing 10 pages). If the validated data is now in hidden fields, couldn't someone alter that data (with evil intent) requiring re-validation? Wouldn't storing the data in sessions avoid that? That said, hidden fields certainly have their place and are probably "good enough" for generic usage. Just a thought. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: [Proposal]newforms render can use subtemplate
On 12/14/06, limodou <[EMAIL PROTECTED]> wrote: > > I saw that newforms has meny output methods, just like: as_table, > as_p, as_ul, etc, and someone also want to add as_dl. And I also saw > that the output is hardcoded in the source code. In my personal > woodlog project, I made an easyform app, and I can render a form with > a subtemplate, so user can change these templates, and this will make > the representation is separated from the soure code. So I think > newforms can also support this appoach. > > Just a suggestion. > Could you make your code available? Perhaps file a ticket and upload a patch? -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Regarding the copy of forms -> oldforms
On 12/18/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > in changeset 4208 all the code from django/forms was copied to > django/oldforms. Isn't that a little bit twisted? Now there's the > same code twice, and any future patch for forms needs to address > both trees. > But only for the short time before newforms are moved to forms. This way those who are still using oldforms can get everything adjusted to working with oldforms while not breaking any calls to forms as described here: http://www.djangoproject.com/documentation/newforms/#migration-plan -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: proposal: get_or_none QuerySet method
On 12/18/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > I often find myself writing code like: > > try: > user = User.objects.get(pk=user_id) > except User.DoesNotExist: > user = None > > What do you think about adding a get_or_none QuerySet method? > > def get_or_none(self, **kwargs): > try: > return self.get(**kwargs) > except self.model.DoesNotExist: > return None > Or how about using something similar to QuearyDict's get(key, default)? That way the fallback is not restricted to `None`. So something like this: user = User.objects.get(pk=user_id, default=None) Of course, I think that would probably be significantly more work than your little wrapper function. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: proposal: get_or_none QuerySet method
Nice job Honza. I was about to suggest just about the same, but hesitated because of the *args and **kwargs. I just wasn't sure why that made me hesitate. On 12/18/06, SmileyChris <[EMAIL PROTECTED]> wrote: > > On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > > something like this: > > > > user = User.objects.get(pk=user_id, default=None) > > Except this would break (or at least limit the functionality of) > objects which use "default" as a field name. > > Now I know why. Good call SmileyChris. Unfortunately I have no ideas for a workaround. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: login_required decorator and redirect_to
On 12/21/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
I've got a particular case that I wonder if it is worth submitting a
patch for...
I do not have an /accounts/profile/ URL and for the site I'm building
it doesn't make sense to have a profile page. But I do need
login/logout functionality and am using django.contrib.auth. I'm also
providing "Login" and "Logout" links in the navigation of the site.
When the user clicks on a URL who's view is decorated by
login_required, they get sent to the login page and the hidden "next"
form field is populated correctly. No problems here.
But, if they click on the login link directly, "next" is empty, and so
it defaults to /accounts/profile/.
You can always populate "next" yourself in your template. The
resulting url would look something like this:
Login
That way, when a user directly clicks the login link, they will be
directed back to that same page after logging in. Of course, that
won't help when someone directly types the address of the login page
into their address bar.
What I'd like to do is create a patch that allows one to specify the
default redirect_to field when next is empty so I can override the
/accounts/profile/ setting.
Usage would look something like this in the urls.py:
(r'^login/$', 'django.contrib.auth.views.login', \
{'template_name': 'account/login.html', \
'default_redirect_to': '/'}),
Worthwhile?
I think so.
In the meantime, I can set up a redirect from /accounts/profile/ to /,
but this seems hackish to me.
Cheers!
Rob
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: proposal: get_or_none QuerySet method
On 1/3/07, Gary Wilson <[EMAIL PROTECTED]> wrote: Ok, after getting sidetracked by update() and update_or_create(), back to the topic of the OP. Here are some options: 1) Add a get_or_none() method that returns None if object does not exist. 2) Add a get_or_default() method that accepts a "default" keyword argument, the value of which gets returned if object does not exist. If a default is not specified then None gets returned by default. 3) Modify the current get() method to accept a "default" keyword argument as in option 2), except that instead of returning None if "default" is not specified, a DoesNotExist exception is raised like normal. To return None, you would have to explicitly say "default=None". Note that this would also be backwards incompatible in that models with a field named "default" would have to use "default__exact=..." instead of "default=..." as with get_or_create(). Looking further, it looks like functions that use get() might also have to change slightly, i.e. get_or_create(). Comments/votes/suggestions? I like 3, but considering the potential complications 2 may make more sense. Either way, I don't see the value in 1 as in either 2 or 3, the default can still be set to None. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Newforms and hidden fields
On 1/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
Hi All,
I've been using newforms in anger recently, and I've hit a bit of a
hurdle. There might be an obvious way around this, but I can't see it.
If you define a form, you can instantiate it with no data, or you can
instantiate it with complete data (binding the form). However, what if
you only want to provide _some_ data?
The immediate use case for me is hidden fields. The user can't fill in
a hidden field, so this data must come from the form initialization;
but if you provide a sparse data set on initialization, the first
presentation of the form will list all the non-initialized fields as
having errors.
But only if you validate the form. If you never call is_valid(), the
form will never be checked for errors and no errors will display.
Thinking more broadly, I can see this problem popping
up elsewhere - e.g., filling some of the visible fields on a form with
initial hint values.
There is the `initial` parameter which could be used in such cases.
That way one wouldn't need to pass data in when initializing the form.
Is there some way around this? Or is this a use case we have missed?
Prior to `initial` being available, I created a static (although is
could be a dynamically populated) dict, and passed that in when
initializing a blank form. Being I never validated the form, no errors
appeared. So that is another option. My view looked something like
this:
defaults = {'foo' : 'bar'}
if request.method == "POST":
form = MyForm(request.POST)
if form is_valid():
# do stuff
return ... # probably a redirect
else:
form = MyForm(defaults)
return ... # display the form
I have since moved my defaults to `initial` in the form definition and
dropped the defaults dict. However, if one needed to dynamically
determine the defaults based on some variables (perhaps User or
Session data), the above works just fine. The great thing about it is
that is_valid is only every called on posted data (not initial data)
and the form is displayed without errors on initial data but with
errors on invalid posted data.
I don't see any missed use case. I know I've seen a few recent posts
here on the list where people are getting the nesting of if
statements, form initialization, and validation wrong, which I
attribute to lack of documentation more than anything else. But maybe
I'm missing something.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Newforms and hidden fields
On 1/5/07, Waylan Limberg <[EMAIL PROTECTED]> wrote: Prior to `initial` being available, I created a static (although is could be a dynamically populated) dict, and passed that in when initializing a blank form. Being I never validated the form, no errors appeared. So that is another option. It is now appears that that functionality may have changed. I assumed it still worked that way but the new docs indicate otherwise. Sorry for the miss-information. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: test suite fails in release 4293
On 1/8/07, Michael Radziej <[EMAIL PROTECTED]> wrote: Hi, after I've updated to svn release 4293, django's test suite fails with this message, using mysql 4.1.12 and python 2.4: == FAIL: Doctest: modeltests.model_forms.models.__test__.API_TESTS -- Traceback (most recent call last): File "/home/mir/lib/python/django/test/doctest.py", line 2156, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for modeltests.model_forms.models.__test__.API_TESTS File "/home/mir/src/django/trunk/tests/modeltests/model_forms/models.py", line unknown line number, in API_TESTS -- File "/home/mir/src/django/trunk/tests/modeltests/model_forms/models.py", line ?, in modeltests.model_forms.models.__test__.API_TESTS Failed example: f.clean_data Exception raised: Traceback (most recent call last): File "/home/mir/lib/python/django/test/doctest.py", line 1243, in __run compileflags, 1) in test.globs File "", line 1, in ? f.clean_data AttributeError: 'CategoryForm' object has no attribute 'clean_data' -- As of changeset 4284 [1], the behavior of clean_data was altered. It looks like the tests in tests/modeltests/model_forms/models.py were not updated to reflect that change. Specifically, I see no calls to is_valid() which would explain the above error. [1]: http://code.djangoproject.com/changeset/4284 -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: test suite fails in release 4293
On 1/8/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
As of changeset 4284 [1], the behavior of clean_data was altered. It
looks like the tests in tests/modeltests/model_forms/models.py were
not updated to reflect that change. Specifically, I see no calls to
is_valid() which would explain the above error.
[1]: http://code.djangoproject.com/changeset/4284
Unfortunately, I don't have the means to run the tests right now, and
I don't recall if calling form.errors (when it returns an empty dict
{}) has the same result as is_valid() (when it returns True), but in
either case, the test which uses invalid data needs updating.
Specifically, the result of line 111 ( f.clean_data) should not be
blank but return an error:
Traceback (most recent call last):
...
AttributeError: 'CategoryForm' object has no attribute 'clean_data'
Insert those three lines between lines 111 & 112) and run the tests
again. If that doesn't do the trick, then in the three tests before
that, either insert a line before or in place of `f.errors` calling
`f.is_valid()` that returns `True`.
Sorry, I'd do it myself, but can't right now. Perhaps I'll get a
chance on my lunch break and submit a patch if no one else has.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: select_related() changes
On 1/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'd like this to become core functionality as I feel its needed. For that to happen, you will likely need to do everything listed here [1]. That includes writing some unit tests for the new functionality and documentation explaining how to use it. In both cases they should be submitted as diffs, just like the code. You can attach each as a different file, or include everything all in one diff file. [1]: http://www.djangoproject.com/documentation/contributing/#patch-style -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Should Django be HTML agnostic?
On 1/11/07, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>
> Rob Hudson wrote:
> >
> > 1. Display code should be separate from logic. Ideally, all HTML would
> > be in template files that one could override if need be in their own
> > template directory, just like the admin templates. If django.forms did
> > this, that would be great.
>
> The forms framework I wrote out of frustration with django.[old]forms
> did this. I ended up with a number of tiny one-line templates. The
> template for a TextField, for example, was:
>
> size="{{ size|escape }}" value="{{ data|escape }}" {% if maxlength
> %}}maxlength="{{ maxlength|escape }}"{% endif %}{% if widget.readonly
> %} readonly="readonly"{% endif %}{% if widget.disabled %}
> disabled="disabled"{% endif %}/>
>
Well if we look at the render method of a basic Input widget [1]:
74 def render(self, name, value, attrs=None):
75 if value is None: value = ''
76 final_attrs = self.build_attrs(attrs, type=self.input_type,
name=name)
77 if value != '': final_attrs['value'] = smart_unicode(value)
# Only add the 'value' attribute if a value is non-empty.
78 return u'' % flatatt(final_attrs)
It should be easy to see that passing final_attrs into Andrew's
template would give the desired result (perhaps with a few
adjustments. It shouldn't be to hard for someone to hack up such a
variation. Then when defining the form, just point to the custom
widgets.
That said, Adrian pointed out elseware that he does not want to tie
the forms to the template system (keeping everything modular) which I
understand. However, if there was a way to pass final_attrs for each
field in a form to the template (perhaps as an optional behavior),
that would give template authors complete control over the layout of
their forms. Perhaps something like:
http://code.djangoproject.com/browser/django/trunk/django/newforms/widgets.py
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Should Django be HTML agnostic?
On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> However, if there was a way to pass final_attrs for each
> field in a form to the template (perhaps as an optional behavior),
> that would give template authors complete control over the layout of
> their forms.
I thing I approached that kind of backwards. Let me try another way:
So summarize the basics that everyone already knows: Currently, if a
Form instance is passed in the context to the template as `form`, if
we have:
{{ form }}
The entire form gets rendered (using as_table()). If we do:
{{ form.as_p }}
Then the whole form gets rendered using as_p(). Yet, for finer grained
control, if we do:
{{ form.field1 }}
{{ form.field2 }}
{{ form.field3 }}
or, perhaps more simply:
{{ for field in form }}
{{ field }}
{{ endfor }}
Then each field gets rendered with any surrounding html defined only
in the template.
Why not take that a step further and allow something like this:
{{ for field in form }}
{{ ifequal "text" field.input_type }}
{{ endif }}
{{ endfor }}
or perhaps:
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: ANN: Upgrading code.djangoproject.com
Nice job guys. Should make things much more clear. Since the update I noticed that this page [1] no longer works. Thing is, it's the only one with a problem that I could find (not that I checked every page) and of course it is the one I wanted. [1]: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/markup/tests.py -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Some ideas for Django ;)
On 2/5/07, Henry <[EMAIL PROTECTED]> wrote: > > Hi. > > On Feb 4, 11:26 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > 1. Full if support - if/elif/else with python access - It could be > > done in the view but making a loop in view and second one in template > > isn't a nice solution. > > Obviously there can be a difference of opinion, And its those differences that motivated the separation of the different components of Django. There is absolutely nothing stopping you from using another templating system. Sure, some of the shortcuts (render_to_responce, generic views, etc) expect Django's templates, but they're only shortcuts for convenience. Nobody has to use them. In fact, if you search this list (and perhaps the wiki) you'll find people have successfully used other templating systems with ease. My understanding is that Django's templating system was built on the idea that as little logic should go into the template as possible. Asking for more logic will likely fall on deaf ears. Just pick your alternate of choice and go to work. That's the beauty of Django. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Some ideas for Django ;)
On 2/5/07, Henry <[EMAIL PROTECTED]> wrote: > > You're preaching to the converted :) Sorry Henry, that comment wasn't met for you, but the original poster. I was just building off of your comment. Perhaps I didn't make that clear. > > On Feb 5, 11:19 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > > On 2/5/07, Henry <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi. > > > > > On Feb 4, 11:26 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > 1. Full if support - if/elif/else with python access - It could be > > > > done in the view but making a loop in view and second one in template > > > > isn't a nice solution. > > > > > Obviously there can be a difference of opinion, > > > > And its those differences that motivated the separation of the > > different components of Django. There is absolutely nothing stopping > > you from using another templating system. Sure, some of the shortcuts > > (render_to_responce, generic views, etc) expect Django's templates, > > but they're only shortcuts for convenience. Nobody has to use them. In > > fact, if you search this list (and perhaps the wiki) you'll find > > people have successfully used other templating systems with ease. > > > > My understanding is that Django's templating system was built on the > > idea that as little logic should go into the template as possible. > > Asking for more logic will likely fall on deaf ears. Just pick your > > alternate of choice and go to work. That's the beauty of Django. > > -- > > > > Waylan Limberg > > [EMAIL PROTECTED] > > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Newforms styling suggestion
On Thu, 15 Feb 2007 20:58:27 -0500, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 2/15/07, Brian Morton <[EMAIL PROTECTED]> wrote: >> I don't know if this has been suggested yet, but has anyone considered >> an >> enhancement to newforms to optionally allow a field to have a different >> class if it has an error? It would be helpful for things like making >> error >> fields highlighted red, etc. Just a thought. > > Hey Brian, > > I think we might have discussed this before, but the discussion > fizzled out. What would you want to style -- the form HTML tag itself? > The ? The table row (in case of as_table())? > > Adrian > I'd realy like to see this as well. I suppose either way would work, but which is used needs to be consistent across all as_methods. Either isn't always the containing block element or its always the label or it's always the form element. The more I think about it, different people will want to apply the style to one of any of those three possibilities. The only way to be able to do so consistently is with the containing block. Oh, and rather than "a different class" it should add an **additional** class. We don't want to remove any classes that already exist. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: newsessions
On Wed, 14 Mar 2007 20:34:11 -0500, Arvind Singh <[EMAIL PROTECTED]> wrote: > >> 1. Manually seeding the RNG with a value unique to the server process, >> or to the request, would move the probability of key collision closer >> to what it "should" be, thus dramatically reducing the problem. > > Problem is reduced... but still remains. > >> 2. Changing the session framework's behavior so that it stores the >> session in the database as soon as it finds an unused key (e.g., by >> looping with 'get_or_create' until it gets a new object) would >> drastically reduce the odds of two independent processes with the same >> key each thinking that their key is unused. > > Very inefficient for a generic module widely in use. > >> 3. Changing Django's ORM to separate INSERT from UPDATE would make it >> impossible for two processes to each execute a 'save' on sessions with >> the same key and think that they each created a new row. > > Ideal solution, exactly what it should have been in the first place. > Instead of ugly reinventions of integrity enforcements, this should be > left to be handled by the database -- where exactly it belongs. > >> Options 1 and 2 are relatively easy and could be implemented quickly. >> Option 3 is attractive, but would be harder to do. > > I don't think this would be any harder than: > > while True: > session.id = generate_new_session_id() > try: > session.insert() > except: > continue > > What I don't understand is: Why the developers don't do the correct > thing by providing separate insert() and update() in addition to > save() ? All it requires is a trivial refactoring and actually > simplifies the code (also clarifying the intent of the programmer). Because doing so would introduce some backward incompatibilities. Therefore, if this solution is considered it will *only* be considered *after* 0.96 is released. That said, this is still a bug that needs to be addressed at some level prior to 0.96 and that is were options 1 & 2 come in. > > The problem is not alone with sessions but any CRUD view. And that is why it has been said a few times already that this will be looked at when QuerrySet is refactored - again, *after* 0.96. I'd really like to see separate insert() and update() as well, but to push for them before 0.96 would be wasting my breath as the devs have made is very clear (here and elsewhere) that that is not going to happen as they've promised backward compatability on 0.96. > > Say you get input from normal users. And your current policy is that > users may only add new data but can't change existing data (typical > for comments, forums, feedbacks etc.). Now, if you just construct an > object from user supplied data and simply call save() -- on > maliciously crafted data -- you may end up overwriting existing data! > > Without availability of INSERT, the only way you can save yourself is > by doing get_or_create() (or something similar) -- which is twice as > slow. Why imitate C when we have exceptions in Python? And I heard > something about being "perfectionist"... > > Silently overwriting existing data has always been stupid, especially > when the data has come from humans! > > Regards, > Arvind > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: The with template tag with "and" operator
On Mon, 02 Apr 2007 10:53:39 -0400, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Hi guys!
>
> I want to be able to use with as:
>
> {% with some.complex.variable as var and some.another.variable as
> other %}
> {{ var }}
> {{ other }}
> {% endwith %}
>
> I saw some discussion about this sometime ago but I could not find the
> thread. Now it is not possible to use the "and" as I want, is this a
> design decision or do you accept patches?
>
If I recall correstly that was a design decision as you can always nest
with tags:
{% with some.complex.variable as var %}
{% with some.another.variable as other %}
{{ var }}
{{ other }}
{% endwith %}
{% endwith %}
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: required=True in newforms Fields does not result in an change in as_p
There's already a ticket on this (3512) with a few patches and discussion. I would suggest marking your's as a duplicate. http://code.djangoproject.com/ticket/3512 anders conbere wrote: > ugh.. forgot to include a link to the ticket I made with my patch in it. > > http://code.djangoproject.com/ticket/4024 > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Generic view patch submited
On Sat, 2007-05-05 at 16:09 -0300, Mi Reflejo wrote: > I don't know which is the way to submit patches, i just added a ticket > with the attachment (http://code.djangoproject.com/ticket/4225). > > Is this the right way?. > Yes. For specifics see the docs [1]. [1]: http://www.djangoproject.com/documentation/contributing/#submitting-patches > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > I think what you're overlooking is that in some cases the issue of > whether its the "best solution" is irrelevant. If the database is > already in production or the policies are already set or controlled by > an external entity, then debating the merits of the single DB, single > connection philosophy is pointless. > > Since we're all into historical anecdotes :) lets take a look at the > COM/CORBA school of thought. What you seem to be missing is that the core devs are not questioning that. Rather, they are all in situations were they don't need multi-db support. Some here seem to have taken their explaination to mean they don't want mutli-db support. But that it *not* what they said. In fact, when the multi-db branch started (over a year ago) they seemed eager to see something they could include into trunk. Unfortunelty, that something has not materialized as noone (that needs that feauture and can therefore adequeatly test it etc.) has stepped up to the plate to finish development and comitt to long term maintanence. Remember, the core devs are all doing this in their free time not-for-pay. Therefore, they are are scratching their own itch. Your welcome to scratch yours as well. Sure, someone mentioned the possability of some money for development, but that doesn't cover the long term maintianence, which is what the core devs are looking for. This same debate has been played over and over for all of the stagnet branches and, quite frankly, I'm getting tired of the pointlesness of it all. No wonder Adrian and Jacob never (rarely?) respond to these kinds of messages anymore. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: auth.User refactor: reboot
On Tue, Mar 20, 2012 at 1:17 PM, Alex Ogier wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >> if settings.USE_LONG_USER_FIELDS: >> username = models.CharField(max_length=255, unique=True, ...) >> else: >> username = models.CharField(max_length=30, unique=True, ...) >> ... > > Maybe, but there's a lot more than username length that people want to > change. Adding piecemeal settings to manage all this is putting wallpaper > over gaping holes. It's not a good long-term solution. > I have to agree, but I don't think it was intended to be a long-term solution. All the other proposals include an entire scheme for defining your own User model. But, aren't we eventually going to get the Apps re-factor (from past GSOC) anyway? Why would a scheme be implemented and released to only have another scheme which accomplishes the same thing be included within the next couple releases? Now we have two ways to configure which User model to use. Are we then going to depreciate the method introduced only a release or two before? Sure, the Apps re-factor could be abandoned for one of these other proposals, but the Apps re-factor benefits a lot more than the User model. However, if the Apps re-factor is still a go (when ready), then something like Nan's simple proposal above seems to me like a more sensible intermediate approach. Although I might suggest wrapping the entire model def in a single if statement rather than individual fields. That way, we get the immediate needs (longer email, etc) addressed with an interim solution but have only one path (Apps re-factor) to the broad solution down the road. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.
Tai, The idea behind errors='replace' is that any chars that cannot be properly decoded as unicode will be replaced with an acceptable unicode char (something like '?'). So, if you want to avoid crashing your program on bad input, this is the only acceptable approach and, I assume, why the current approach was taken way back when Django was converted to be all unicode all the time (internally). However, you bring up an interesting edge case. Apparently the replacement char is causing an invalid SQL statement to be generated - which breaks things in ugly ways. Probably not what we want. I see a couple approaches to this: 1) This could fall under the 'we need better error messages' umbrella and it should be easier to determine what the bad SQL statement was. 2) One could argue that errors='replace' is mangling user input and really an error should be returned to the user, allowing them to fix the error in the form and resubmit. I'm not sure which approach is the way to go here. However, forcing users to deal with encodings is generally a bad idea. Besides, you never can trust a browser to give you what it says it is giving you. In other words, the user may not be able to get the browser to send the correct encoding anyway. For those reasons I'm leaning toward #1. Of course, that begs the question: should Django be doing a better job escaping the data used to build the SQL statement? I guess we won't know unless we get the bad SQL statement. Which takes us back to #1. On Thu, Mar 29, 2012 at 5:42 AM, Tai Lee wrote: > I've just created an essay *cough* I mean ticket about the way Django > silently mangles POST data that is incorrectly encoded, and how this can > send someone (like me) down the rabbit hole trying to debug it, thanks to > "current transaction aborted" database errors. > > This shouldn't normally happen, but it seems that I am unlucky and someone > somewhere is able to get their browser to submit POST data that is encoded > incorrectly. > > I don't want to repeat myself too much and end up writing another essay > here, so I'll just link to the ticket. Just wanted to post this here as well > because jezdez said it might be better suited to discussion on > django-developers. > > https://code.djangoproject.com/ticket/18004 > > Cheers. > Tai. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/ByLiu7RzHtIJ. > 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. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Improve Django markdown rendering.
On Thu, Sep 6, 2012 at 8:22 PM, Thomas Purchas wrote: > I have submitted a path to improve the way Django handles html in markdown. > Specifically how it escapes it. > > Ticket 6526 has all of the detail, could someone please review my patch. > As the maintainer of the Python-Markdown library, I'll weigh in here. I'll start by noting that safe-mode was a poorly chosen name for the feature (which was added before I joined the project). Really, it is a means of restricting raw html and IMO, should only always "escape" raw html. However, because of the word "safe" in the name, the feature has grown to support other so-called "safety" features to avoid XSS (for example injecting malicious JavaScript into a markdown style link) etc. That said, I can make no claims that it is actually "safe". The "replace" option is supported for backward compatibility reasons (also why it is still the default) and "remove" is really just a shortcut for "replace" with the "html_replacement_text" set to a blank string. Not sure why anyone would want either of those options. Remove is too surprising to the document author and replace is a lousy (IMO) attempt at an explanation. While escape might not be expected by the author, once noticed, it not nearly as surprising. If someone wants "safe" output from Markdown, I recommend using a library specific to that purpose like bleach [1]. In fact, it would make more sense to me to create a separate "clean" filter (perhaps called "clean_html"?) which calls `bleach.clean()` and provide it as a filter that can be used with any of the markup languages offered by Django. If instead, improvements are only going to be made to the markdown filter, then I would suggest a complete overhaul allowing access to all of markdown's features [2]. For example, markdown outputs xhtml by default. Some may want html - which the markdown lib supports - but the Django filter does not. To me, the markdown filter in its current state is completely useless. I have always had to re-implement my own, more powerful solution. My recommendation is to do one of the following (in order of preference): 1) Remove contrib.markup (per Django's depreciation policy) and leave it to third party apps to support. 2) Completely refactor the markdown filter to support all of the markdown library's features except for "safe_mode" and add a new "clean" filter which can wrap any markup filter. 3) Add a new "clean" filter and simply drop support for Markdown's safe_mode - leaving the rest as is. I do not recommend the approach of the current patch. It leaves a bad taste in my mouth. Also note that I do not recommend supporting Markdown's "safe_mode" in any form. Of course, the Django team will need to make whatever decision will better serve the community - not me. [1]: https://github.com/jsocol/bleach [2]: http://packages.python.org/Markdown/reference.html#markdown -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: contrib.markup deprecation
On Sat, Oct 13, 2012 at 1:34 PM, Luke Plant wrote: > Hi all, > > https://code.djangoproject.com/ticket/18054 > > I just came across this, and it seems slightly hasty. Most deprecations > of entire contrib modules would require some discussion on django-devs, > I would have thought. The most recent discussion of this on the list was here (although I do remember it being mentioned previously): https://groups.google.com/forum/#!msg/django-developers/tRpwMudkCfo/pVIPk8QvRusJ Luke, perhaps you missed it as it was about markdown. I link to it now because it includes my take (as the maintainer of the markdown lib) of the current markdown implementation in contrib.markup. Someone else in this discussion mentioned that the markdown implementation is not safe. I believe that it the case with all "true" markdown implementations. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On Wed, Jan 2, 2013 at 1:36 AM, Victor Hooi wrote: > Hi, > > I may have missed it, but has been a fundamental shift in how Django looks > at projects versus applications, and how they should be laid out? > > I get the impression from Alex Gaynor's comments above that the concept of > "projects" is on it's way out? > > I know there was a change in project layout with Django 1.4, but I thought > things were still more or less the same as before - and projects were still > in. > > James Bennett wrote a blog post way back in 2006 about projects versus > applications: > > http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/ > > I'm wondering if anybody from core is interested in updating that to reflect > current best practices, and the future direction of Django? > James updated his position on that almost exactly one year and one month later: http://www.b-list.org/weblog/2007/nov/09/projects/ My recollection is that the basic premise discussed in that post has been the general view of all core developers since that time (if not before). Search the archives of this list and you'll find various discussions about this - mostly proposals to update the tutorials to not use the "project" concept. Unfortunately, no one has stepped up to do the work. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Remove download_url from setup.py
On Wed, Apr 3, 2013 at 7:46 PM, Russell Keith-Magee wrote: > > On Wed, Apr 3, 2013 at 5:29 PM, Donald Stufft wrote: >> >> Just an idea. >> >> I think it might make sense to remove the download_url from setup.py. It >> has caused problems in the past >> (http://www.djangoproject.com/m/bad-installer.txt) and I don't think leaving >> it there adds much value. It does however add yet another place that a >> package releaser needs to update and makes `pip install Django` more >> fragile. >> >> The only major benefit I can see is providing a download link on PyPI, but >> given that there's a link right 40px or so to directly download from PyPI >> and a giant green download button further up the page I think this benefit >> is minimal. >> >> Thoughts? > > > Responding mostly because nobody else has, not because I have any firm > opinions on the topic. > > Logically, download_url strikes me as being bit odd - the package metadata, > which you obtain by downloading the package, contains the definition for > where to download the package. If the only purpose of the download_url > declaration is to set the link on PyPI, and pip will install from PyPI's > uploaded version of the package by preference, then I don't see any real > benefit in having the download link. > > However, I'll completely defer to anyone with more experience with the > internals of pip or setuptools/distribute/whateveritscalledthisweek. > > Russ %-) > > > > -- > 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. > > If I'm not mistaken, the only part of the download url that changes with each release is the version number -- which is referenced only a few lines up. Why isn't the url dynamically created using version? That's what I do for my projects and the problem has gone way for me. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: CSRF Middleware/SSL/Firefox 3.6.8 bug
On Fri, Aug 27, 2010 at 8:19 AM, Florian Apolloner wrote: > On Aug 27, 12:20 pm, Mat Clayton wrote: >> Any >> chance of getting some of the core dev's to think about removing additional >> SSL checks, as FF 3.6.8 is a pretty major browser to support and this is >> likely to only get worse as adoption increases. Is the additional security >> worth the trade off? > > I doubt that. It will only get worse if users use crappy addons; it's > not a firefox problem per se… > Well, at least your right that it is not (only) a firefox problem. Regardless of what browser I use or what settings I have set, here at work behind a firewall, all HTTP_REFERER headers are striped. If any app requires that header, I can't use it and there is nothing I can do about it, except wait till I get home. As I expect is the case with many, I just don't bother trying later if it didn't work the first time. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: ANN: Improving our decision-making and committer process
On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee wrote: > On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant wrote: >> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote: >> >>> My suggestion is about this unfortunate ticket status -- 'Accepted'. >>> This now works as a sort of a dusty shelf: when anyone of the core team >>> looks at the patch and decides that there's nothing wrong with it he >>> puts it on that shelf where the ticket has all the chances to lie for >>> months or even years. And if the author of the patch tries from time to >>> time pitching it to get it into trunk he can easily fall into all sorts >>> of "not-a-good-times": conferences, feature freezes, hot discussions on >>> other topics etc. >>> >>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch >>> is good it should be committed right away. If it's not there have to be >>> an explanation why it needs improvement or why it's going to be >>> wontfixed. Simple waiting doesn't really improve quality of the patch. >>> >>> What do you think? >> >> This doesn't account for these facts: >> >> 1) Accepted != Ready for checkin. >> 2) A lot of triage is done by people without commit access. >> >> Sometimes a ticket stays at 'Accepted' for a long time because it >> doesn't actually have anyone motivated enough to write even a patch, or >> tests etc, which means that it is de-facto low priority, and we >> shouldn't feel guilty about this kind. The ones in the 'Ready for >> checkin' queue are the ones that deserve to be checked in, and it >> currently has only 35 in it, compared to 1226 in 'Accepted'. > > This is an important stat -- but it glosses over the fact that 1226 > "accepted" tickets doesn't necessarily clarify how many of these have > viable patches -- or patches at all. > > Accepted tickets can be: > > * Purely accepted, indicating that someone has verified that the > problem exists, but not how to solve it > > * Accepted with a patch that is wrong in some way (e.g., fixing the > symptom, not the problem) > > * Accepted with a patch that is missing documentation or tests > > * Accepted with a valid patch, just awaiting review by someone else. > > A ticket in the first three conditions patently isn't ready for > checkin. A ticket in the last condition *may* be ready for checkin; we > ask for independent verification before it gets moved to RFC. So, in other words, accepted simply means that the ticket reports a valid bug or feature request that is considered worth fixing, but offers to indication as to the status of any patches for committing. Obviously, some seem to imply the later meaning into "Accepted" which could raise the question regarding whether it is named correctly (I say it is fine). But, more importantly, is there a place were each status is simply defined? Sure there is this: http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage But that hardly makes clear exactly what "accepted" actually means. The text in that section is helpful to understanding the basic process, but if someone changes the status of my ticket, there's no definitive place to go and see exactly what that status means. In fact, in reading the list over the last few years, I have the impression that this is a problem that is repeated constantly. People don't understand what the various statuses mean and get frustrated when things do not happen as they expected. I think perhaps clearer documentation would help in this case. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: #11930 - submitting patches against djangoproject.com files?
On Sat, Dec 4, 2010 at 8:48 PM, Greg Turner wrote: > Hi, > I have a patch for #11930 that in to be applied against djangoproject.com's > base.css file. As far as I can see, base.css is not in the project > repository. Who is the custodian of this file, and the other CSS files? Is > there a reason it's not in the repo? If you go back through the wiki history you'll find this [1] on the startpage: > djangoproject.com: See the full code and templates for the Django-powered > portions of this site (e.g., everything except the ticket system). The Python > code is available under the BSD license, but the templates are copyrighted > by World Online and shouldn't be copied. I always assumed this was why the css wasn't included in the repo. But now that that note has been deleted (4 years ago - wow, time flies...) I don't know what the situation is. Will the community redux change this? [1]: http://code.djangoproject.com/wiki/WikiStart?action=diff&version=259 -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Problem with ``Model.objects.create``
On Tue, Jan 4, 2011 at 10:54 AM, Yo-Yo Ma wrote: [snip] > The difference in Django is that instantiation doesn't represent > "creation". Saving to the database does, and since the ORM is an > abstraction of the database, you don't care that the DB is ok with an > empty VARCHAR value. You only care about your model's required value. > I'm suggesting this: > > class Person(Model): > name = CharField(max_length=50) > > >>>> Person() # Should work fine (assign attributes later, etc) >>>> Person.objects.create() > ... Should raise some kind of exception before allowing your model's > "INTEGRITY" to be violated. > No it shouldn't as no data validation has been run. Remember, like save(), create() does not run validation on the instance before writing to the db. As Russ pointed out, the actual data written to the db is valid as far as the db is concerned. Therefore, you get no errors. If you want to ensure the data is valid (as defined in your python code - not per the db) then you need to validate it in python *before* writing to the db. Therefore, don't use Person.objects.create() That being said, it does strike me as being a little odd that there is no way to validate your data when using create() or get_or_create(). In fact, the docs [1] describe both those methods as shortcuts. But if you're writing an app that always needs to validate your data, then you will never use those shortcuts which makes them rather useless. Of course, they existed long before (the current) model validation mechanism did, so I wonder if it would be reasonable to propose that they (at least optionally) be updated to run validation before saving. Or perhaps a warning in the docs that create() and get_or_create() do not run validation before writing to the db may be appropriate. [1]: http://docs.djangoproject.com/en/dev/ref/models/querysets/#create -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Contributing Guide Request For Input
On Sat, Feb 19, 2011 at 6:49 PM, Gabriel Hurley wrote: > I've added a patch to ticket #14401 based on the contributions people made > to the wiki. This is the final call for comments and review before it gets > officially added. > Thanks! > - Gabriel Hurley I realize the docs don't generally link to specific wiki pages, but following Russ's comment on another thread, it occurs to me that perhaps it would make sense to point people to the "Reports" page were they can find a number of useful trac queries to find tickets to work on. I get the impression a number of people don't realize this page exists then request that feature x be added to trac - only to have it pointed out that feature y accomplishes the same thing. These requests are often motivated by frustration that their pet ticket doesn't stand out in trac queries - when they're just not trying the right queries. Just a thought. On Tue, Feb 22, 2011 at 6:22 AM, Russell Keith-Magee wrote: > > ... along with 313 other tickets. I've just added this query to the > "reports" page [1], which is itself linked from the > code.djangoproject.com home page. A range of other queries have always > been there, but there wasn't a simple "needs review" query. > > [1] http://code.djangoproject.com/wiki/Reports > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Reshaping the "Contributing to Django" documentation
On Fri, May 20, 2011 at 5:31 AM, Julien Phalip wrote:
> Hi there,
>
> I've been working on reshaping the documentation about contributing to
> Django, in particular the rather dense historical page [1] and the
> excellent recently added how-to guide [2]. This documentation has sort
> of grown organically over the years and has become a bit difficult to
> read, so I tried to improve things a bit.
>
> I've submitted a patch in the designated ticket:
> http://code.djangoproject.com/ticket/15796
Awesome!
One nitpick thought. I expect that people reporting bugs will go to
the "bugs-and-features" page, which is fine. However, as is often the
case, when their ticket is marked "accepted" (or some other triage
stage) they often get confused about what that means (as we all know).
If they are only looking to get their one ticket fixed, I doubt they
will find on there own the explanations of the various stages now
under "triaging-tickets" ("I just want my one ticket fixed. I don't
have time to work on other peoples tickets, Why would I look there?").
Perhaps a link to those explanations should be added to the
"bugs-and-features" section? Just a thought.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
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: Python 3 and you
ots of years, before 2.7 disappears. Hopefully, by then, > others will have been running 3.x versions for years, and will have > long since worked out the kinks. > -- > Vernon > > -- > 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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: List of DDN Tickets
I had a few comments on some of these and was going to post them to the tickets so they don't get lost, but my browsers acting up and closing when I try to login, so I'm posting here. On Wed, Jun 18, 2008 at 7:58 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: [snip] > > * http://code.djangoproject.com/ticket/2259 - I think the right action to > take would be to make the PK editable=False. Modifying the pk, to me, seems > like trying to relocate a c++ object instance in memory-- it sounds like a > big pain and not that much benefit (none). Agreed. If a user really wants to edit a PK, then they can either do custom sql or add a new row and delete the old one. > > * http://code.djangoproject.com/ticket/4996 - I don't know if it would be a > good idea to make 'runserver' run as a daemon. Maybe it would be ok of there > was a warning before forking. The argument made in the ticket is that offering a daemon option for runserver could give a false sense of stability of the dev server so it doesn't belong in the core. That said, a use case was made for adding it for dev purposes only. Interestingly, the last activity on this ticket was before apps could add their own management commands [6400]. Seeing the given use case is not likely to be used by most, I'd say this belongs in a third party app (like perhaps http://code.google.com/p/django-command-extensions/) and those few people who have a valid need for it can still get the feature that way. [snip] > > * http://code.djangoproject.com/ticket/6709 - I think this is a no-go. It > would be overly complex. If I'm understanding the request correctly, this could only be used by forms that can only work with js. Generally speaking, creating an interface that doesn't have a fallback when js is disabled is considered bad design. Why would we add a potentially complex feature only for the support of arguably bad UI design? Just a thought. > > * http://code.djangoproject.com/ticket/6932 - Having a list of flatpages > would be good. I am in favor of making them available to the templates; > either in the RequestContext or a templatetag. Either way would probably be > beneficial. The current patch only adds the list of flatpages to the Context in the flatpages view. However, a user could conceivably want access elsewhere in his project. At the same time, we don't want to waste resources on every request when it's not needed. A templatetag makes the most sense to me. It could easily be loaded into any template and used from any app. Additionally, while its a nice-to-have feature, I don't see it as a pre-1.0 deal breaker. Anyone could add a templatetag to there own app. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Experimental Git repository available
On Thu, Jun 19, 2008 at 1:52 PM, Alexander Solovyov <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 19, 2008 at 8:09 PM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: >> Yeah, hgsvn is one-way, > > H > >>hg help convert > hg convert [OPTION]... SOURCE [DEST [REVMAP]] > > Convert a foreign SCM repository to a Mercurial one. True, but that doesn't address pushing changes back to SVN, at least not practically. Mercurial's own docs [1] admit this is a problem needing improvement. Compare that with git-svn's dcommit command [2]. [1]: http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion#head-15564b76f3172721218d34c912aa0c31e156a94b [2]: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Spam detection
On Thu, Jun 26, 2008 at 4:34 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > El jue, 26-06-2008 a las 13:31 -0700, Jacob Kaplan-Moss escribió: >> Help me out here: how can I make it more obvious? You missed that; >> others often do to. Can you share with me some insights on how you >> missed it? > > The sentence should be more prominent, I know nobody that will read that > many lines, so maybe bolding "spam" and "register for an account" would > make those a bit more visible. Yeah, it does kind of get lost in the text there. The first few lines basically say "be sure you actually have an unreported bug." Presumably, the potential reporter thinks: "Yeah, Yeah, I've been through that before so why should I read every point in that list carefully?" True, first time reporters to any project probably should read that, but obviously they don't. Personally, I alway look for a "register" link in the menu - usually in close proximity to the "Login" link. I'd suggest (and have in the past) that a "Register" link be added to every Trac page right next to the "Login" and "Settings" links up in the top right corner. If that doesn't work - then perhaps a dancing animation across the newticket page. Ok, maybe not. :-D -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. <[EMAIL PROTECTED]> wrote: > > Nice thing about GETs is that users aren't confronted with the dreaded > "Data was submitted with POST" confirmation, which is confusing to > most people and usually not tested. Basically you end up breaking the > back button and the reload button. Um, this is intentional and a good thing. If you read the spec, not only is the difference between GET and POST defined, but the way user agents (browsers) should treat them is defined as well. Breaking the back & reload buttons is a requirement of the spec to, among other reasons, avoid multiple posts by impatient (or double-clicking) users. Granted, browsers could provide more helpful messages, but we want that behavior for POSTing data. Which leads me to the question: In what use-case would a FormWizard ever GET? GET is only to be used to retrieve data (i.e.: search results) whereas POST should be used when submitting data to the server. I can't think of any case where a multi-page form would be used to "retrieve" data. I realize Jeremy suggested that POST would still be used on the final page, but even so, the other pages technically are still POSTing data. Perhaps he wants to allow the user to stop part way through a wizard, bookmark the url (with the data entered thus far preserved in the querystring), and allow them to pick up where they left off later.? Interesting, but I wouldn't recommend it. For one, that could result in some long urls (perhaps even longer than the limit). A multi-part form could add up to a lot pretty quick. Second, those would be some ugly urls. And third, as mentioned above, it's not really the proper use of GET anyway. So, unless a strong use-case is provided, I'm -1 on this. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. >> <[EMAIL PROTECTED]> wrote: >>> >>> Nice thing about GETs is that users aren't confronted with the dreaded >>> "Data was submitted with POST" confirmation, which is confusing to >>> most people and usually not tested. Basically you end up breaking the >>> back button and the reload button. >> >> Um, this is intentional and a good thing. If you read the spec, not >> only is the difference between GET and POST defined, but the way user >> agents (browsers) should treat them is defined as well. Breaking the >> back & reload buttons is a requirement of the spec to, among other >> reasons, avoid multiple posts by impatient (or double-clicking) users. >> Granted, browsers could provide more helpful messages, but we want >> that behavior for POSTing data. > > What specification requires this? > A number of them actually. To name a few: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13 http://www.w3.org/2001/tag/doc/whenToUseGet.html A decent summary of the issues are found here: http://www.cs.tut.fi/~jkorpela/forms/methods.html -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7591: Authenticate By Email Support
Paul, I believe this issue has been brought up in various ways before. I'd suggest searching the list archives and old closed tickets. You'll likely find your answer there. More generally, there is already a mechanism in place to override the default behavior and implement your own (building your own auth backend), so I suspect the core devs would prefer that you do that rather than build everyones minor feature request into the core. Actually, I believe there are at least a few existing solutions out there. A search should turn up a few gems for you. On Wed, Jul 2, 2008 at 11:48 AM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > I've been using Django for a while and recently started contributing to the > trunk. Previously I ran my own branch but sooner or later that gets > tiresome. So I created a ticket the other day: > > http://code.djangoproject.com/ticket/7591 > > The ticket suggests a patch to contrib/auth that will allow authenticate by > email as well as username. The idea was shot down rather quickly without > any particularly good reason. In order for me to continue contributing to > the trunk I'd like to get in line with the thought processes on Django > development. Could someone here please elaborate on why ticket 7591 is a > bad idea? Or better yet why its a worse idea than other approaches? > > > Thanks, > -- > - Paul > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: rev 7920 fresh checkout fails tests?
On Mon, Jul 14, 2008 at 12:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
[snip]
> File "D:\u\kmt\django\trunk\tests\regressiontests\admin_scripts\tests.py",
> line 56
> cmd += ''.join(' %s' % arg for arg in args)
> ^
> SyntaxError: invalid syntax
>
> (the caret points to the 'r' in 'for' in fixed-pitch font)
>
> Same django checkout works if I just use python 2.5.1 instead. Is this new
> syntax not supported by 2.3?
>
It would appear so:
Python 2.3.4 (#1, Nov 20 2007, 15:18:15)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [a for a in ['1','2','3']]
['1', '2', '3']
>>> ''.join(a for a in ['1','2','3'])
File "", line 1
''.join(a for a in ['1','2','3'])
^
SyntaxError: invalid syntax
>>> ''.join([a for a in ['1','2','3']])
'123'
However in 2.4:
Python 2.4.3 (#3, Jun 8 2007, 04:52:26)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ''.join(a for a in ['1','2','3'])
'123'
>>> ''.join([a for a in ['1','2','3']])
'123'
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Views returning data only
Vicvicvic,
I think your on to something here. However, we need to remember that
one of the great things about Django views is that they are just
python functions. You can do pretty much anything you want. So, if
someone wants to build up a complete html page in python code without
any templates, they can. It will be a maintenance headache, so it's
not recommended, but its not wrong.
If you want to build up a library of decorators that simplify your
views (and, no doubt, speed up your work), then you are free to do so.
And if you want to share that library with others, that's even better.
In fact, if you search through djangosnippets.com, I believe you'll
find a few snippets that do some of the same things your talking
about.
However, I don't expect that the Django core will take on your
approach as the "preffered" way to do things. The flexibility of the
views to allow various coding styles is one of Django's greatest
strengths. You can do what works for you and I can do what works for
me.
So keep it up. Share your work and make Django a better place for
others who like that style of coding. Just don't expect the entire
community to embrace it as the "only way".
On Tue, Jul 15, 2008 at 6:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> In the Django FAQ, we can read this about views:
>
>>In our interpretation of MVC, the "view" describes the data that gets
>>presented to the user. It's not necessarily how the data looks, but which
>>data is presented. The view describes which data you see, not how you see it.
>>It's a subtle distinction.
>
> In my mind, "which data you see" would be equal to a context a view
> returns, not the HttpResponse or the template. Why? Because rendering
> a template is saying "I have this data and I want it presented the way
> this template will present it". If the view is responsible for saying
> that, it is at least partly responsible for telling us how we see the
> data.
>
> Rather, if a view ONLY returned a dataset, something else would be
> responsible for displaying this. In more practical terms, if a view
> returns a dataset, instead of a full response, another mechanism would
> be wholly in charge of formatting the data. This mechanism may then
> choose which template to render, or to not render a template at all,
> and just pass the dataset along.
>
> Why is this useful? For the sake of minimizing views, but provide a
> rich amount of formats. The format-choice mechanism can investigate
> the request (HTTP Requests come with an Accept-header) and see what
> format has been requested. Looking at Accept would be the proper way
> of doing it, but it might be easier to make URLs like /forums/threads.
> (?Phtml|json|xml)
>
> HTML? Render that template. JSON? Render that template (or just
> serialize the dataset). XML? RSS? You get the idea: The formatter
> takes the data and tries to present it, making it a bridge between a
> view and a template.
>
> Furthermore, the same mechanism could be asked to process an
> "internal" request, that is another Python function requesting the
> data. Right now, I have a couple of views which return some data. But
> I'm also building another view, and I want the data from one of the
> first views in this one. I can either duplicate the fetching from the
> first one, or I can send an "internal" request and just get the
> dataset. I pick WHICH data I want and add some to it.
>
> My current solution:
>
> I've written a very crude decorator to demonstrate/use this in my own
> projects, but I'm note sure if posting code looks any good on Google
> Groups. Summarized:
> My decorated views return their dataset as a dictionary.
>
> The decorator takes two parameters: template and formats. template is
> the usual path to a template, but without an extension. formats is a
> tuple of formats (('html','json')) which the view is considered able
> to render.
>
> Upon calling the view, the decorator intercepts its arguments. It
> looks for a format-parameter and an internal-parameter. If internal is
> True, it lets the view run and just returns the resulting dictionary
> to whatever called it. If not, it checks that format is in formats and
> then tries to render_to_response("%s.%s" % (template, format,
> returned_dict, RequestContext(request))
>
> As I said above, the mechanism (in my case, a decorator) should
> probably try to investigate what the request looks like, rather than
> checking for stuff in the URL/other parameters but as I said, it's
> crude. It should also return the proper Content-type.
>
> --
>
> Do you think I have a point? Me not being a Dja
Re: QManager - suggested inclusion in Django
On Thu, Jul 17, 2008 at 6:46 AM, zvoase <[EMAIL PROTECTED]> wrote: > > Dear Developers, > I've written a module which may be helpful to a lot of Django > developers, and would like to suggest it for trials and testing, and > possible inclusion with Django. Well, for starters, it appears to be licensed under the GPL while Django had a BSD license. As long as the conflict exists, your changes of inclusion are pretty slim, I would think. Either way, don't get your hopes up for inclusion any time soon. Everyone is currently working to get 1.0 out the door and this is not a show stopper for that (it doesn't break backward compatibility of the API - just adds new stuff) so I doubt the core devs will even consider it until after 1.0. In the meantime, review the points on contributing [1] in the docs, continue to maintain your code as separate code and prove your worth as a reliable maintainer. [1]: http://www.djangoproject.com/documentation/contributing > I'm currently just looking for > developers to help test and work with the module; it should be quite > helpful. It certainly looks interesting. Perhaps I'll play with it if I get a chance. > It's also heavily documented - *everything* has a docstring. I hope > you enjoy, I'll say. What, less that 50 lines of code in a 500+ line document? Wow. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: url template tag, unhelpful when failing
On Fri, Jul 18, 2008 at 3:09 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Fri, 2008-07-18 at 19:30 +0200, Mikael Moutakis wrote: >> Hi >> I've running from trunk and recently switched to the NFA-branch. I >> found that the URL templatetag is unhelpful when failing to match a >> url. I patched my own copy of the function URLNode in >> django.template.defaulttags to return a more helpful error message >> instead of a empty string. Should I file a ticket with the patch or >> should I add the solution as a django snippet instead? Sorry, if this >> is a stupid question, but I'm new to this. I modified the last 3 lines >> of the function below. > > > The basic design rule is that template tags should always fail silently > if there's an error. Some templates and applications rely on this > behaviour. So a change like this runs against that principle. > In other words, a patch like that will likely not get applied. However, others may find it useful, so a snippet may be the way to go. However, I wouldn't just post your patch as a snippet, but post a full working tag that would be added to a users app, which can then be used in place of the one that ships with Django. If your interested in more specifics as to why Django has chosen silent failure, search the list archives. Seems there was a recent discussion about it. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Call for testing: new docs
On Wed, Aug 20, 2008 at 2:36 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: >> I've also put a built version of the docs online at >> http://docs.djangoproject.com/dev/. There are some problems with the >> version online right now; no need for bug reports since I'll be >> changing the online version to better fit into the django site over >> the next few days. > > Hi, Jacob! > > Does "no need for bug reports" apply only to presentation or to content > as well? I'm asking because I've found an old-style `class Admin` your > request declaration in an example in "Django at a glance" and I'm not > sure if such bugs are known. > There's already a ticket for this: #8150. Although the patch might need to be adjusted for the new docs. http://code.djangoproject.com/ticket/8150 -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: '"%s/" % var' preferred to 'var + "/"'?
Well, according to the python beginners book; "Dive Into Python" [1], string formatting is less error prone as it also does type coercion whereas string concatenation only works when all objects are already strings. When it's possible that a user will be passing in parts of the concatenation, I'd rather be using formatting for that reason alone. I had thought that I read from that same source that formatting is faster than concatenation (and that's why I checked there before responding), but I don't see that mentioned. Not sure where I got that idea or if its even true. [1]: http://diveintopython.org/native_data_types/formatting_strings.html On Thu, Aug 21, 2008 at 11:41 AM, Joost Cassee <[EMAIL PROTECTED]> wrote: > > Hi all, > > Just a quick question to set my head right for future Django > contributions. Why is "%s/" % var better than var + '/'? I can think > of some reasons: 1) consistency with other code, 2) certainty of > string concatenation. But is the second expression not much faster? > (This is an honest question, no criticism or anything.) > > Regards, > > Joost > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: '"%s/" % var' preferred to 'var + "/"'?
On Thu, Aug 21, 2008 at 12:22 PM, Ian Kelly <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 21, 2008 at 10:00 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >> I had thought that I read from that same source that formatting is >> faster than concatenation (and that's why I checked there before >> responding), but I don't see that mentioned. Not sure where I got that >> idea or if its even true. > > Formatting is faster than serial concatenation, which often results in > copying the same substring multiple times. A single concatenation is > usually faster than formatting, however. > PEP 8 has something to say about this under "Programming Recommendations": - Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Pyrex, Psyco, and such). For example, do not rely on CPython's efficient implementation of in-place string concatenation for statements in the form a+=b or a=a+b. Those statements run more slowly in Jython. In performance sensitive parts of the library, the ''.join() form should be used instead. This will ensure that concatenation occurs in linear time across various implementations. Of course, this doesn't say anything about formatting - just joins, but concatenation seems to be generally discouraged wherever we look. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Checkboxes in admin
On Fri, Aug 22, 2008 at 1:12 PM, Alex Rades <[EMAIL PROTECTED]> wrote: > > Hi, > Is there a reason for checkboxes (BooleanField) in admin having the > label on the right side instead of left? Isn't that how check boxes are generally displayed? I don't recall them the other way anywhere - and would find that confusing. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: user-friendly API for multi-database support
On Wed, Sep 10, 2008 at 3:30 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>> Model.
>
> That's a very interesting point, and one I hadn't considered. It makes
> sense to allow people to over-ride the connection used by an
> application they didn't write - for example, people may want to tell
> Django that django.contrib.auth.User should live in a particular
> database. Further-more, just allowing people to over-ride the
> connection used for an existing application isn't enough - you need to
> be able to over-ride the default get_connection method, since you
> might want to shard Django's built in users (for example).
>
> This in definitely one of the use-cases we need to cover.
>
> I'm not sure of the best way to handle it though. The way I see it the
> options are as follows:
>
Would this perhaps be easier to do after the Apps-Refactor (#3591)
lands? I'm not real familiar with that ticket, but if we're trying to
set a connection on a app level - that seems like the easiest way to
do it via settings. Something like:
INSTALLED_APPS = (
app('django.contrib.auth', connection='my_user_db'),
...
)
Not sure how that would work for over-riding the default
get_connection method though. We'd probably still be referring to a
callable by 'dotted.path.to.a.function' syntax. And it would apply to
all models in an app, not just some.
Just a thought.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Status report on CPython 2.6
Search the archives. This has been discussed a few times before. I believe someone (Karen?) has even been testing for 2.6 compatibility and a few changesets have been committed specifically for that purpose. IIRC, the policy is to support 2.6 where-ever practical as long as it doesn't break support for 2.3-2.5. Again, the previous discussions will provide answers - although, now that 1.0 is out, I suppose an update on that status wouldn't hurt. On Fri, Sep 26, 2008 at 1:09 PM, zvoase <[EMAIL PROTECTED]> wrote: > > Hi, > Just wondering if I could ask how compatible Django is with CPython > 2.6. I know that it should work fine anyway, but I thought it a good > idea just to check. Has anyone looked into this? > > Regards, > Zack > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: "things are ready" signal?
On Wed, Oct 1, 2008 at 5:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > > So, would a signal there be useful? (no ticket filled yet) And, where > can one hook code for that? :) > I seem to recall this request being made from time to time. IIRC, it always turned out that whoever asked didn't really want this, but something else. Therefore, I don't believe anyone has provided a valid use case for such a signal. I'd suggest searching the archives. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Google maps subclass of GeoModelAdmin
I'm not really sure, nor am I the one to make such a decision, but I wonder if perhaps something like this hasn't been included because of issues with Google's licensing. Of course, not everyone is using GeoDjango in a commercial setting, so your code's still useful. Perhaps you could post it on djangosnippets.org. However, if I'm wrong about the licensing issues, a ticket with a patch would be the way to address inclusion. On Wed, Oct 15, 2008 at 7:07 AM, Thamsanqa <[EMAIL PROTECTED]> wrote: > > Hi > I see that only open street maps are supported by GeoDjango in > django.contrib.gis.admin through the OSMGeoAdmin class which inherits > from GeoModelAdmin. I have discovered that changing this to use Google > Maps is a matter of modifying the template files in contrib/gis/ > templates/gis/admin and then pointing a new class inheriting > GeoModelAdmin to one of them. How can I contribute the modified > templates and subclass to the Django project, that is if there is any > interest in adding this to django ? > > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: admin.autodiscover() uses method that cannot find files inside of eggs: possible fix included
On Wed, Oct 22, 2008 at 7:16 PM, Clint Ecker <[EMAIL PROTECTED]> wrote: > > Hi all, > I've opened a ticket on this matter (http://code.djangoproject.com/ > ticket/9427) but the gist of it is this: > [snip] > > I'm throwing this out there just to get a wider eye on the patch just > in case there are any edge cases that these changes might affect. > What about an admin.py in an egg that legitimately raises an error on import? If imp.find_module can't find it as you claim, won't that error be eaten? Now, I realize that should probably be caught while testing not in an egg first, but it is a real possibility. Perhaps we shouldn't care about that one though. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: [Pony] Per app settings
On Thu, Oct 23, 2008 at 1:29 PM, shabda.raaj <[EMAIL PROTECTED]> wrote: > > I was doing a little research and saw #5049, which was closed as > WONTFIX by Russell, but I cant seem to find the referenced discussion, > and am posting this as maybe this proposal is significantly different > than what was discussed in the past. :) My understanding is that any app specific stuff is to come under the planned INSTALLED_APPS refactor in #3591. There are also some notes on the wiki[1]. Personally, I have no idea if the plan includes a way for app specific settings files or not, so this may or may not address your pony. In any event, I seem to recall is being pointed out before that the settings file is just python code. There is noting stopping you from importing other app specific settings files into settings.py. Presumably, you would want to do such an import at the end of the file so as to override the project defaults. Although, rereading your request, that wouldn't do what you want. The thing is, settings are loaded once at server init and remain unchanged across requests. However, you want settings to change for each request depending on which app a view resides in. That's determined in url resolution. Remember a url.py file in one app could point to a view in another app. Perhaps a wrapper (or decorator) around your views could add the appropriate context. Settings are global and constant, they're not the place for this sort of thing. [1]: http://code.djangoproject.com/wiki/InstalledAppsRevision -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 2:49 PM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? > I see two problems with this: 1. This current behavior is fully documented [1]. In relevant part, the documentation says: > This doesn't control whether or not the user can log > in. Nothing in the authentication path checks the > is_active flag, so if you want to reject a login based > on is_active being False, it is up to you to check that > in your own login view. However, permission checking > using the methods like has_perm() does check this > flag and will always return False for inactive users. 2. Many people have expected the current behavior for some time and such a change would be backward incompatible. Although, I do see that the documentation specific to the login_required view does not specifically mention the behavior. Perhaps a note there would be beneficial. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#api-reference -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote: > > I think http://code.djangoproject.com/ticket/3357 should be given > another look at enabling optional multi-threading on the dev server. > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > threading, especially when it could be very useful. We don't even know > if there are multi-threading bugs. And even if there are, they can be > fixed. > Yet, the time spent identifying and fixing those buds means less time developing real features that I need and can use on my production sites. I'd say the developers time is better spent elsewhere. Especially considering there are already working solutions out there. I seem to recall at least one management command someone put together that runs a multithreaded cherrypy server. Why reinvent the wheel? Lets focus on real, useful features. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
>> ...
>>> # Using RequestContext
>>> def myview(request, *args):
>>># some code here...
>>>request.render('template_name.html', {...})
>> ...
>>>
>>> That just seems logical to me. Rather than (potentially) break
>>> backwards compatibility, let things be as they are right now and just
>>> add a method to the request.
>>
>> Except that it couples request and response objects to templates.
>
> But render_to_response also does that?
> You want request and response to be loosely coupled? Does it make
> sense? Aren't they coupled in render_to_response and response
> processing code anyway?
>
> Please explain your point a bit more.
>
render_to_response is a "shortcut" that makes a few assumptions to
cover a common use case and helps keep your views DRY. If you changed
your template system or various other pluggable components, you would
either need to write your own version of render_to_repsonse or repeat
yourself often in your views. However, by making render a method of
the request, we are now taking those assumptions another level and
forcing them on the request object itself. That's bad.
You see, anyone can use Django any way they want and don't have to use
any of the "shortcut" helper functions. However, everyone has to use
the request and response objects, so the code needs to make as few
restrictive assumptions as possible in those objects. And yes, making
it easy for someone to use a different template system is a feature
that we want to keep.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: The Django form HTML is rendered as TEXT
Hi Dmitri, Welcome to Django. However, this list for the development of Django itself, not development with Django. Please ask your question on the django-users list. <http://groups.google.com/group/django-users> -- Waylan Limberg way...@gmail.com On Thu, Dec 25, 2008 at 10:44 PM, Dmitri_13 wrote: > > > Hi Guys, > I am new to Django . My Django form HTML is rendered as TEXT . It does not > display the HTML as such. > > Please assist. > > Thanks in Advance > Regards > Dmitri > -- > View this message in context: > http://www.nabble.com/The-Django-form-HTML-is-rendered--as-TEXT-tp21171407p21171407.html > Sent from the django-developers mailing list archive at Nabble.com. > > > > > -- Waylan Limberg way...@gmail.com --~--~-~--~~~---~--~~ 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: django + rest
Hi Ed. This seems more like a question for the django-users list. django-dev is for the development *of* Django, not development *with* Django. Ask there, and I'm sure you'll get pointers to a lot of helpful resources. For a start, you may want to take a look as Malcolm's recent multi-part series on the subject. Note the third one with regard to content-types. http://www.pointy-stick.com/blog/2008/12/09/implementing-http-services-django/ http://www.pointy-stick.com/blog/2008/12/13/etags-and-modification-times-django/ http://www.pointy-stick.com/blog/2008/12/15/content-types-http-and-you/ On Mon, Dec 29, 2008 at 8:28 PM, Ed Summers wrote: > > I was wondering if anyone else on the list has layered a RESTful > service into their django applications. I'm adding an atompub > interface to an existing django project, and I'd like to offer the > ability to POST and PUT to URIs. Part of my problem is that this > service needs to handle large (many megabyte) file uploads, so the > POST and PUT message body needs to be streamed to disk, rather than > held in memory. > > I took a look at the FileUpload functionality in > django.http.HttpRequest and > django.http.multipartparser.MultiPartParser, and it looked like I > could slot in custom handlers as long as the content was POSTed with a > mimetype of "multipart/form-data". Unfortunately I am wanting to allow > clients to POST and PUT arbitrary content (application/zip, > application/atom+xml, etc). > > At the moment I'm rolling my own code to read from request.environ > ['wsgi.input'] but I'm worried that I'm not handling everything > correctly, and am wondering if there exists middleware for handling > this sort of scenario in a cleaner way. Or perhaps there's a more > django-y way of doing it? > > Any info/pointers/tips would be appreciated. > > //Ed > > > > -- Waylan Limberg way...@gmail.com --~--~-~--~~~---~--~~ 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: Multiple attach files...
Hi Marcello, This list it for the development of Django itself. For usage questions, use the django-users [1] list. Or, you may find the django-brasil [2] list more helpful. [1]: http://groups.google.com/group/django-users [2]: http://groups.google.com/group/django-brasil On Mon, Feb 2, 2009 at 11:02 AM, Marcello(Harry) wrote: > > Hi every one, > my name is marcello, i'm from brazil, i'm new here and i'm not expert > with django but i try! =) > So... i have some question about multiple attach files, > if multiple attach file have discussed here before!? > Can i try dev this new models class or classes!? > > sorry about my english... > > att, > > Marcello Bontempo Salgueiro. > > > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: module to run django under mod_fcgid
On Mon, Feb 2, 2009 at 8:57 AM, Mike wrote: > > I tried to post this to the django ticket system but got rejected by > the spam filter twice (prompting me to leave a rude message, I > apologize). If there is any interest in this, could someone advise > where to post the code? Thanks. > Hey Mike, If your register [1], the spam filter gets turned off. If you would prefer not to register, you can create a session key with the session settings [2], which will make the spam filter less aggressive. Last I checked, this was explained on the spam rejection page. Once you do that you could put your sample config on this wiki page [3]. Of course, you always could post it to djangosnippets.com as well/instead. That seems to be the go-to place for posting django code snippets these days. [1]: http://www.djangoproject.com/accounts/register/ [2]: http://code.djangoproject.com/settings [3]: http://code.djangoproject.com/wiki/ServerArrangements -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: MarkupField
On Sun, Feb 22, 2009 at 4:46 PM, James Turk wrote: > > > What about other types of markup? > Some have suggested supporting more types of markup but to me this > seems outside the scope of contrib.markup which currently only > supports ReST, markdown, and textile. Should this field not meet some > peoples needs the can add their own custom markup field and base it on > this design. > Well, at the vary least, you could make it easier for one to add their own type of markup. Perhaps make the render-markup function such that one could provide their own render function without needing to subclass the field. Personally, I would use this every time as I will never use the default markdown. I will always be adding in some of the available extensions[1]. Currently, the only way to do that is to write my own render method. It would be nice to just pass that in on declaring the field without creating my own subclass etc. [1]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: MarkupField
On Sun, Feb 22, 2009 at 8:40 PM, James Turk wrote: > >> First, I don't think you actually addressed the question mentioned in >> the ticket regarding the 3 fields. It seems the question was whether >> there should be three attributes on the Python model instance, >> regardless of how many columns are stored in the database. On this >> note, though, I do have a thought: specify the markup type as an >> argument to the MarkupField. You already do this with a >> default_markup_type, but I don't see much use in having users specify >> their markup type at the time they enter the text. > > I'm fairly attached to the idea of the type being tied to an instance > and not to the field itself as to me this feels much more flexible > (examples of where I'm using this behavior on live projects are on a > multi-user blogging app we use at my office where I tend to write my > posts in ReST, some coworkers prefer raw HTML, and some also use > Markdown). I agree with you about passing this complexity on to an > end user, comments for instance should support one and only one > format, but by setting a default this is possible (yes it is storing > an extra integer per record in the database but this seems > forgivable). > Actually, I think there's room for a few different behaviors. Not sure that all of them should go in contrib.markup, but I see 4 possible scenarios: 1. James current implementation where each instance has the formatter set for that specific instance. 2. Marty's suggestion where the formatter is hard-coded into the model definition. 3. And a ForeignKey dependent option. Imagine a User or Project specific setting. Perhaps something like: class Project(models.Model): name = models.CharField(max_length=50) formatter = models.IntegerField(choices=MARKUP_CHOICES) class Page(models.Model): project = models.ForeignKey(Project) body = markup.MarkupField(formatter='project.formatter') I would imagine the above would work like Option 2, in that whatever formatter is set for the 'Project' is assumed for all 'Pages' in that project. No need to store the formatter_type separately in the 'Page' model. 4. However, in some situations, I could see Option 3 used in conjunction with option 1. The User sets her default choice in her User Profile. Then, whenever she creates a new instance, the formatter defaults to her preferred formatter. However, this particular instance may use a different type of formatter, so she selects a different formatter on that instance - which needs to be saved specific to that instance. Hmm, guess I'm kind of proposing two different things here aren't I? 1. Per instance formatter or not. I have a couple thoughts about how to differentiate this one. The obvious way would to have two different Fields, one for each behavior. However, what about this crazy idea: only offer one Field, but have to keywords options: "default_formatter" & "formatter" (or whatever color you choose). If "default_formatter" is set, then use that as the default, but give the end user the option of selecting a different formatter per instance. However, if "formatter" is set instead, then set that formatter for all instances with no option for the user to change it. Obviously, it would need to be worked out how to handle having both set (ignore one, generate error, or something else), which could get ugly, but I thought I'd throw it out there. 2. ForeignKey dependent default or not. Again, the obvious way would be with different fields. But what about checking to see if the string passed in matches an existing foreignkey on the model, and using that if it does - falling back to the current behavior if not. Again, this may be a bad idea. Just throwing it out to generate some thinking on it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: MarkupField
On Mon, Feb 23, 2009 at 7:09 PM, dc wrote: > >> * it removes the ability to provide multiple markup_types on a given field > > No if properly implemented. Again, see FileField upload_to for > example. Or see the django-template-utils app [1]. It provides a nice wrapper so that all the formatters use the same API. You probably don't need to do exactly that, but something similar with a dict to map names to functions. Then pass that dict in as an argument. [1]: http://code.google.com/p/django-template-utils/source/browse/trunk/template_utils/markup.py -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
