Re: Proposal: default escaping (and branch request)
Simon Willison wrote: > On 20 Jun 2006, at 16:25, James Bennett wrote: > > > Security by annoyance is security that people learn to hate and turn > > off as soon as they can, so in the end it doesn't really make them any > > more secure than they were before. > > Agreed - which is why I want to try it in a branch and see if it's > actually annoying :) > > Cheers, > > Simon All, Would it be possible to do a validation test against the templates at startup, and/or with a separate utility? Something like : #python manage.py cktemp appname I guess I was thinking of something like XML validation. The advantage of this is that it wouldn't be automatically manipulating anything, just letting you know that there is a problem. I'm not really supportive of anything that would encourages bad practice. For example HTML was so unrestricted that you could get away with almost anything, with XHTML you actually have to do things properly and validate your work. Thanks! --Nick P.S. Sorry if I missed a similar suggestion in an earlier thread :) --~--~-~--~~~---~--~~ 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: Generic Auth and Row Level Permissions
Chris, Thanks for keeping us in the loop! Row Level Permissions and Generic Authorization are probably the most important new features in Django for me at the moment so its nice to know that things are going well. I'm really looking forward to using it on my current project. Many thanks to all for the hard work! -- Nick --~--~-~--~~~---~--~~ 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: JavaScript and Changeset 3541
> Hopefully that answers some of your concerns. I'm curious as to the > communities take on it, if in general the opinion is to remove it then > I will. I personally think the admin interface would work well with > some AJAX built into it, but I know that isn't the case with everyone. > Comments? Concerns? > > Chris AJAX integration is a nice touch, but I think that the use of YUI goes against the established use of Dojo with Django. After reading the proceeding threads in this post, a couple of questions come to mind: 1. Chris, would it be reasonable to move your work to Dojo? 2. Project leaders, if Chris were to move his Ajax work to Dojo, would it be well received? --Nick --~--~-~--~~~---~--~~ 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: JavaScript and Changeset 3541
Malcolm Tredinnick wrote: > On Wed, 2006-08-09 at 19:25 -0700, Linicks wrote: > [...] > > AJAX integration is a nice touch, but I think that the use of YUI goes > > against the established use of Dojo with Django. > > Where are we using Dojo at the moment? > > Malcolm Malcolm, I'm not sure how much it's being used in the current trunk, however it has been discussed many times. Here are a few links that may interest you. - http://blog.dojotoolkit.org/2006/02/01/dojo-django - http://lazutkin.com/blog/2006/jan/28/django-dojo/ - http://article.gmane.org/gmane.comp.web.dojo.user/3603 - http://spoken.phrasewise.com/articles/2006/02/01/django-adopts-dojo-as-ajax-framework - http://groups.google.com/groups/search?q=django+dojo+integration&; --Nick --~--~-~--~~~---~--~~ 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: BigIntegerField
I have wanted this as a built in "Type" for some time. I usually just do some manual SQL to alter the columbs that I need to be "Big Integers", but it would be nice to have them built in, especially for the default row id created for each table. Hopefully this will make its way into the trunck sometime soon. --Nick --~--~-~--~~~---~--~~ 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: Dynamic Menus...
Take a look at the js option (http://www.djangoproject.com/documentation/model_api/). --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SOC Integration Plan/Policy/Timeline
Now that the "Summer Of Code" projects are complete, is there a plan/policy/timeline for integrating these branches with Trunk? Thanks! --Nick --~--~-~--~~~---~--~~ 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: generic-auth and per-object-permission integration
Once (gen-auth/pop) are merged, what are the major barriers in getting that branch merged into trunk? Thanks! --Nick --~--~-~--~~~---~--~~ 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: generic-auth and per-object-permission integration
Chris Long wrote: > Already had a few people point out some bugs and some features they > want. Community involvement is key to get this moving ahead as quickly > as possible. I'm planning to move my development work to the pop/gen_auth branch once they are merged. Hopefully I will be able to give some good feedback at that point. When the merge is complete, would it be possible to have you guys merge with trunk fairly regularly? Thanks! --Nick --~--~-~--~~~---~--~~ 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: RowLevelPermissions and show_all_rows
Jay Parlar wrote: > Are any other people doing much testing with the branch? It'd be nice > to see it get moved to the trunk, but I know that won't happen without > more testers. > > Jay P. I have been waiting for the pop/gen_auth merge, but it looks like that may not happen as soon as I would like, so I will start working with the current gen_auth branch in a couple of days. Besides, waiting a little has allowed you and Chris to weed out some of the initial bugs :) Getting these tools and the other SOC projects into Trunk would be a real boost for Django in general. --Nick Pavlica --~--~-~--~~~---~--~~ 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: RowLevelPermissions and show_all_rows
Linicks wrote: > I have been waiting for the pop/gen_auth merge, but it looks like that > may not happen as soon as I would like, so I will start working with > the current gen_auth branch in a couple of days. This should have read: I have been waiting for the pop/gen_auth merge, but it looks like that may not happen as soon as I would like. I will start working with the current pop branch in a couple of days. -Nick Pavlica --~--~-~--~~~---~--~~ 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: I can't mark a ticket as having a patch.
I have been having issues with Akismet as well. I have submitted a ticket(http://code.djangoproject.com/ticket/2801), so hopefully someone will have a chance to look at this issue. Akismet has been blocking my Wiki updates, but allowed me to submit a ticked without any issues. I have tried it with "anonymous" and my Wiki settings to no avail. --Nick Pavlica --~--~-~--~~~---~--~~ 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: generic-auth and extensible QuerySet filtering
> Does anyone have ideas for what to name this function/method? I > haven't been able to come up with anything I've been happy with. Joseph, I'm not flush with naming ideas at the moment, but thought I would try to brain storm a little. List of my bad names: - FilterPerms - PermFilter - AuthFilter - AuthSet - AuthFilter - AuthorizedCollection - AuthorizedFilter - FilterAuthorized - AuthorizedSet - AuthorizationSet - AuthorizationFilter - AuthorizedObjects - AuthObjects - FilterAuthObjects - LimitToAuth - LimitToPerms - LimitAuthResults - FilterAuthResults I hope this will help spark some ideas. -- Nick Pavlica --~--~-~--~~~---~--~~ 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 auth magic
Here are my two cents, Clearly some work will need to be done to the current authentication system to make it more modular for those that have LDAP, OpenID, etc, as "requirements" for there projects. Having an easy to define authentication mechanism as Brian proposed is also very attractive. My hope is that a default authentication mechanism like the current system will still be available. It doesn't cover every possible scenario, but can be used for a large number of projects, and it's been well tested. Having an easy to use built in authentication mechanism was one of the things that originally attracted me to Django. Thanks! --Nick
Re: Proposal: Validation-aware models
"""c.crime_date = datetime.date(2006, 1, 2) c.crime_date = '2006-1-2' In the second example, c.crime_date would immediately be converted to a datetime.date object. What are the pitfalls to this approach? """ Providing this type of "Magic" is a bad idea because it's not explicit in form, and doesn't promote consistency. """* As a side effect, generic create/update views will not be able to use edit_inline stuff; that will only be an admin feature. I am 100% fine with that, as I have never seen a need for using edit_inline out of the admin -- it is an admin-specific phenomenon. We could indeed expose the logic of determining edit_inline stuff so people can use it for themselves, but it wouldn't be a core part of models, as is currently the case with automatic manipulators. """ IMHO the admin should reflect the capabilities of the framework, but shouldn't be part of it. In theory I should be able to create my own "Admin" application with all of the current features of the existing admin just using the framework. If it was an important feature in the admin application, that functionality will probably be useful to someone else. Essentially, the admin should be the first killer Django application. """* This plan is nice conceptually because it doesn't leave any chance of bad data in any model instance. Currently, Django is "dumb" about data in model instances -- it allows any arbitrary data there, and catching bad data is completely the responsibility of the developer. This can lead to some IntegrityErrors at the database level (search the django-users mailing list archives for examples) when the developer forgets to validate.""" Promoting best practice is good, but having it built in would be GEAT!!! """I would propose to instead do validation in those situations where the data is moved to the external storage - on .save() (or in the unit-of-works .save() if we have them). That way you can happily create invalid objects, but you will be forced to make them valid to save them. An additional .validate() method could be introduced that will trigger validation without saving to allow programmers to do early validation if they need to. All this with bonus points for keeping an internal flag on the object that tells wether this object is "validated" or "dirty" with __setattr__ (or actually property access) automatically marking objects as "dirty", so that the implicit .validate() within .save() isn't needed if early validation was used. """ >From my perspective this proposal is clean, and provides some flexibility for the developer. It may be worthwhile to look at how Rails approaches this problem as a source of ideas: (http://www.onlamp.com/pub/a/onlamp/2005/10/13/what_is_rails.html?page=3) --Nick --~--~-~--~~~---~--~~ 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: Proposal: Validation-aware models
I'm not sure that this is 100% relevant to this discussion, but wanted to share it in the context of this thread. A Python type checking module: http://www.ilowe.net/software/typecheck/ --Nick --~--~-~--~~~---~--~~ 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: {% recurse %} Tag
That looks great! I would like to see it in Django. Nice work! --Nick --~--~-~--~~~---~--~~ 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: Schema evolution
"This is great!" Schema evolution is something that I have wanted since I started using Django. As a safety precaution you could add a warning when you are running the migration/evolution. ex. "Warning This May Destroy Your Data, And Render Your Application Inoperable. Would you like to backup your database?" [yes/no] * If "yes" - Exit the script to backup of the database. * If "no" - Proceed with the migration/evolution without a backup. This will have the added benefit of making the procedure interactive so that the migration/evolution command isn't accidentally executed without some sort of verification. --Nick --~--~-~--~~~---~--~~ 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: MultiAuthMiddleware vs AuthMiddleware
"""RequestUserMiddleware is a horribly ugly name, and in the latest diff attatched to http://code.djangoproject.com/ticket/1428 I've renamed it to MultiAuthMiddleware. I'm wondering if people think it would be worthwhile to add something else called AuthMiddleware that would do more or less what django does now. It would be the default when you created a new project.""" I think that it's important to have a default authentication system similar to the current one. The easy to use and powerful built in system made/makes Django very attractive to me. As a newer user of Django it helps to have as much consistency as possible. In my mind it makes sense to have all of the authentication mechanisms as a plugin/extension/etc. to the MultiAuthMiddleware. You could have a "default_auth" plugin/* that implements the current authentication system by default. If I wanted to switch to LDAP, NIS, or custom mechanism I would just reconfigure the authentication back end. I hope I'm not missing the boat here :) """Also, the stuff in django.parts should move to django.contrib.auth and django.parts should die.""" This appers to be another place to help clarify the API to a new user. The *.auth is more explicit to me than *.parts. Parts could be anything... """It might also make sense to move some of the machinery (AuthUtil, maybe others) down a level into a new django.auth package and/or to put the multiauth stuff in a django.contrib.multiauth package.""" Once again, anything that can be done to provide a consistent and explicit naming and location conventions would really help the learning curve and usability. I'm really looking forward to the new authentication system built around multiple authentication mechanisms in mind. Thanks for the hard work on this! --Nick --~--~-~--~~~---~--~~ 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: Validation-aware models: First stab
All, Validation aware models have seen allot of attention so far with a number of proposals out there. This proposal, like the others, has it's strengths and weaknesses. This method of validating models is a good start, and will surely evolve or be replaced over time. I believe that we need to come to a consensus on this proposal and move forward with it as soon as possible. --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Deadline Driven Development
All, The first thing that you read on the Django project website is this statement: "The web framework for perfectionists with deadlines." I would like to build on the last word in that statement "deadlines". Every significant project has a some sort of deadline, it's about the only time tested method of keeping focus. Clearly they get changed and pushed out from time to time, but they are still there moving things along. The use of the word "deadlines" in the Django projects credo implies that deadlines are an important component of this project. Because deadlines are important, I would like to propose a deadline driven development model for the Django project itself. I envision a very simple model that would have the following components for each release: 1.The release name: Version number and or title. 2.Release deadline date: In the format of (-MM-DD). 3.Optional feature deadline: An earlier date than the release deadline if there are other components that rely on it to meet the release deadline. 4.Required Features: Anything that MUST be done for this release. 5.Desired Features: It would be nice to have, but isn't required. Here is an example entry in the "Release Deadlines" wiki page : Release .9x, "Big Timber", Deadline (-MM-DD) * Required Features: - Sub classing, Feature Deadline (-MM-DD): Summary and or Hyperlink to further resources. - Schema evolution: Summary and or Hyperlink to further resources. * Desired Features: - Data loading for machines via web services or something: Summary and or Hyperlink to further resources. I hope that the advantages of this proposal are evident, however I understand that beauty is in the eye of the beholder. Comments/Concerns/Questions? Thanks! --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
