Re: introduction
Hi Chris, I have a little feedback if you are interested. [Just so you know, I'm a "heavy user" of Django but have yet to make a substancial contribution to the project] In general I think your proposal is fine but I have a few points: -Lots of tables there! Can you acheive the same without the extra tables? I would guess you can come pretty close. I think by narrowing your functionality to *only* deal with the example you provided you can greatly simplify your implementation and the management of the db. -(Somewhat contrary to the suggestion above!) An alternative approach for the group-level changes: a new permission type that allows you to assign a group that can access that object. i.e. permissionA = access for every user in groupA. Then every user that belongs to groupA can access objects created by any user in groupA. You would then, obviously, add the permission to groupA only -How do you deal with those permissions in the generic and admin views? You may need to change the returned lists to show only those things that the user has created? I'm not sure. I know it would be an issue in the admin pages but the generic lists might be used in various ways (and perhaps the option to choose would be nice). Anyway, that's just what came to me when I was looking. Thanks for taking this on! -rob --~--~-~--~~~---~--~~ 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: introduction
> How do you deal with those permissions in the generic and admin views? To be clearer, I meant: How do you deal with those permissions in the generic and admin *list* views? -rob --~--~-~--~~~---~--~~ 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: EVOLUTION - Add Field Schema Evolution Support
> It would be nice if I could have an answer on this, thus I can avoid > redundant effort. Perhaps there would be more confidence in your efforts if it: a) Wasn't making someone else's work redundant b) Came from some detailed design c) Worked on all databases before being checked in If you posted some designs on your wiki then we can at least critique it. I don't think you've described what the "Field Add" functionality is, or how it works, for example. -rob --~--~-~--~~~---~--~~ 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: default escaping
> What do you think of auto escaping being on for .html templates and off for
> .txt templates?
Simon,
Sounds clean but consider:
a) The ever-present argument about file extensions & template syntax
(that we seemed to solve with MR)
b) These can't be so easily extended. For example, to switch your
entire app from non-escaping to escaping you have to rename all your
files. If you set a variable in a base template, you can just add the
tag there.
So I think {% auto_escape_on %} or {% auto_escape_off %} are better
options (depending on consensus to which should be the default).
-rob
--~--~-~--~~~---~--~~
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: How do I populate a combo box from another combo box in admin?
The Javascript way is the only way if both combo boxes are on the same page (i.e. the selection must be initiated on the client side.) You can add extra javascript easily in admin by using the "js" option in admin, so you won't need to actually override any templates. -rob --~--~-~--~~~---~--~~ 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: How to change foreign key deletion behaviour?
> That's what I'm after. But I see no reason why we could accomodate more
> options! =)
For the admin interface, probably your best option is to override the
delete view. This is very simple, actually, because all actions are
directed by the url and can be overridden by urls.py.
So, in your urls.py file, above include('admin/', ...), type in
something like:
(r'(\w+)/(\w+)/(\d+)/delete/$', 'my.delete.view'),
In that view, you can unset the relationship and delete the object in
question, using the project, model and object id args. If you just need
it for one particular model, then hard-code the project and models and
the rest will fall through to the included admin actions.
-rob
--~--~-~--~~~---~--~~
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: How to change foreign key deletion behaviour?
Create your own admin/submit_line.html template. -rob --~--~-~--~~~---~--~~ 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: hierarchical datasets redux
> In the Admin UI it could look like this: [Select State] --[Select County] [Select Zip] I think situations like this are handled better on the server side anyway. A list containing ~100 items or less is appropriate in most cases, but there is a pretty good chance you would exceed this even with the filtering idea you are proposing. What you should ideally use when you are dealing with so many rows is something that filters information before it leaves the server. An example (that won't work exactly in your particular case) is the way raw_id_admin works in the admin. It paginates to 100 items by default, and can filter even more with list_display/search_fields options. It would work even better with some more javascript (e.g. to automatically fill in the field when adding a new item, change the repr() string on the fly, and allow modification of a foreign key entry), but the concept is good and you certainly can't complain about the price. My 2c: as for the exact example you have given, I don't think even selecting zip codes is appropriate in a form. Seems very tedious to select one from a list when it is only five (+4) simple numbers to type! If your goal is validation, that can be done server-side. If your goal is ease of use, stick with a text field. -rob --~--~-~--~~~---~--~~ 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: would this kind of thing be 'contrib' worthy?
> I'm working on something similar at the moment, which indeed be available in > "contrib." It's going to be really awesome. Fantastic! I've been using the admin list views because of these features, but it "gets a bit hacky" after a while! Wouldn't have thought it necessary in contrib (instead just in forms, if it is generic), but same difference. I can hardly wait. -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
specifying newforms-admin options
Hi all, In the newforms-admin wiki there is mention of a "cleaner way to specify admin options". Has this been discussed yet? If so, my apologies. I've kind of been out of the loop for a while. If not, can we start? -rob --~--~-~--~~~---~--~~ 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: specifying newforms-admin options
From a puritanical point of view, I would like to see the admin options separated from the fields. It could also allow for more flexibility. I think a ModelAdmin class in the same file but separate from the Model class would be easiest to manage, if that were possible. Assuming the default use is "just to turn on admin", this would be comparable to the current level of effort. -rob But the bigger question is, should the "class Admin" even live in the model at all, given that it's gaining many more hooks, not all of which are simple data structures. With each hook I add, it feels more and more messy to have that functionality within the model. Of course, having it in the model requires very little typing and no extra Python modules to manage, so if we were to move "class Admin" somewhere else, we'd lose that convenience. The goal of this thread, then, should be to come up with a design that satisfies both requirements: "class Admin" shouldn't feel out of place, yet it shouldn't be a tremendous pain to declare admin options/functionality. Adrian --~--~-~--~~~---~--~~ 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: specifying newforms-admin options
> Something like this is what I had in mind: ...
I generally like the simplicity and explicitness of your suggestion,
but having to manually add & remove models is too fragile, I think.
> Maybe there can be a helper function that looks for all Admin classes, as
> long as you save them in a file called admin.py within the app, but that's
> kind of magic.
If you explicitly reference the module in the urls.py file, it is
simple without feeling magic. e.g.
urlpatterns = patterns('',
(r'^admin/', include('django.contrib.admin.urls'), {'model_loc':
('mysite.polls.models.admin',)})
)
This would rely on introspection to find out which ModelAdmin classes
exist in the module, but it makes it pretty simple to turn it on/off or
add/remove modules (assuming multiple modules can be specified via the
tuple argument).
-rob
--~--~-~--~~~---~--~~
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: order of models per app in admin interface
Isn't is easier just to override admin/index.html? That way you can even add some styling/javascript that will organize it to better suit your needs. If you don't know what I mean: 1) copy the file django/contrib/admin/templates/admin/index.html to yourtemplatedir/admin/index.html. 2) Add yourtemplatedir to your TEMPLATE_DIRS tuple in settings.py 3) edit yourtemplatedir/admin/index.html to fit your needs -rob --~--~-~--~~~---~--~~ 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: Is this group moderated, or is it a bug with google groups?
Its the new google groups, I think. I saw the same thing the other day with the (then beta) new google groups, but had no issues with the old one. -rob On Jan 25, 10:59 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 1/26/07, medhat <[EMAIL PROTECTED]> wrote: > > > So many times I send messages to the group, but my message does not > > appear at all, or it might appear a day or two after I actually send > > it, which of course makes it appear down on the list, and nobody really > > sees it.The list isn't moderated; if a message you post takes a while to > > show > up, it's not because someone is intercepting it and intentionally > delaying it. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 update on newforms-admin branch
On Feb 2, 12:01 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> The Jan. 31 deadline for merging the newforms-admin has passed, so I
> thought I'd give a status update:
Kudos on these changes (& newforms, of course). I really like that
admin is now as "legit" as regular forms for public views - very
efficient & flexible. Very DRY!
> from django.contrib.admin import TabularInline, StackedInline
>
> # ...
>
> class Admin:
> inlines = (
> TabularInline('Child', min=3, max=20, extra=3,
> fields=('name', 'age')),
> StackedInline('Job', min=1, max=3,
> fields=('company', 'salary')),
> )
>
Adrian, that is a phenomenal idea. Succinct and powerful.
Just one q: How would you specify the ordering of these displayed
fields vs. others? e.g. can you say 'field1', 'field2', inline[0],
'field3', inline[1] etc.
-rob
--~--~-~--~~~---~--~~
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: suggestion for a slightly extended {% for ... in ... %} tag
> I find it useful to have the {% for %} tag syntax extended so that one can
> write:
> {% for a,b in L %} meaning the obvious thing
You can do this. a,b return type is implicitly (a,b) in Python. In
other words:
{% for x in L %}
{{ x.0 }}
{{ x.1 }}
{% endfor %}
> Also (maybe more contentious):
> {% for i in L1,L2 %} meaning what one would write in python as:
> for i in zip(L1,L2)
This is starting to look like more logic in the template than you
would normally use. I think the idea of the {% for %} tag has been
(and should be) to be able to easily cycle through collections of data
you've already set up. Most of the time you don't have to manipulate
them in any way other than how you've collected the data in the first
place. If you *DO* need to manipulate them, you should use views, not
templates.
You can also write your own tag to do the same - however, I still
think the work should be done in the view.
My .02
-rob
--~--~-~--~~~---~--~~
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: suggestion for a slightly extended {% for ... in ... %} tag
> You can do this of course but it does not help to make sense of the
> template. E.g.
>
> {% for key,value in L %}
> {{ key }}->{{ value }}
> {% endfor %}
Yes, however you're looking at the case of only two variables. Think
of how unmanageable it will start to look like this:
{% for name,description,value,href in L %}...
It is better to get a dict back from the view instead of creating one
in the template.
-rob
--~--~-~--~~~---~--~~
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: contrib proposal: django-values
> I'm glad you like it! I really hope it does help many other people who > have a need for something like this. I'm very eager to hear what other > thoughts and questions you (and anyone else!) have about it. I'm glad > to clarify. > > -Gul Good timing! I was planning to look to something like this pretty soon - my settings file has been the place for all of this data initially but was getting out of hand. So, my first question is whether this could be designed to work without respect to models. For example, there are a lot of cases where views might refer to the same data, but not the same models. It would seem cleaner if there were a separation (and would avoid complications with inner classes vs. overridden fields). In my particular case, it would be cleaner to simply have a new class (or classes if it is easier to manage) that contains ALL the "constant" data. Was there a reason that you went with field-defined values? I can see the "context" argument, but seems like a lot of extra complexity if that is the only reason. Also, like Adrian I don't like the name as it is now. I think "Constants" is fine. "Config" might also work but seems less specific. Djata, perhaps?! -rob --~--~-~--~~~---~--~~ 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: Problem in XML Serializer with unicode data.
This is a question for django-users, but I'll do the usual "chastise
then help" post :)
The problem is because XML uses settings.DEFAULT_CHARSET of 'utf-8',
which is the standard XML character set. You will need to change this
to 'utf-16', I think.
So, in your settings file, add the line:
DEFAULT_CHARSET='utf-16'
-rob
On Apr 11, 6:06 am, "Saik" <[EMAIL PROTECTED]> wrote:
> Hi people,
>
> Im trying to use the serialize utils in
> django.core.serializers.xml_serialize and
> django.core.serializers.json, i dont have problems using json but i
> have issues trying something like that:
>
> xml = serializers.serialize("xml", Anymodel.objects.all())
>
> If the model data contains unicode characters (example:
> Anymodel.name='España'). The error is the following:
>
> ---
> exceptions.UnicodeDecodeErrorTraceback (most
> recent call last)
>
> /usr/local/lib/python2.4/site-packages/django/core/serializers/
> __init__.py in serialize(format, queryset, **options)
> 65 """
> 66 s = get_serializer(format)()
> ---> 67 s.serialize(queryset, **options)
> 68 return s.getvalue()
> 69
>
> /usr/local/lib/python2.4/site-packages/django/core/serializers/base.py
> in serialize(self, queryset, **options)
> 38 if field.rel is None:
> 39 if self.selected_fields is None or
> field.attname in self.selected_fields:
> ---> 40 self.handle_field(obj, field)
> 41 else:
> 42 if self.selected_fields is None or
> field.attname[:-3] in self.selected_fields:
>
> /usr/local/lib/python2.4/site-packages/django/core/serializers/
> xml_serializer.py in handle_field(self, obj, field)
> 70 value = self.get_string_value(obj, field)
> 71 self.xml.characters(str(value))
> ---> 72 else:
> 73 self.xml.addQuickElement("None")
> 74
>
> /usr/lib/python2.4/site-packages/_xmlplus/sax/saxutils.py in
> characters(self, content)
> 307
> 308 def characters(self, content):
> --> 309 writetext(self._out, content)
> 310
> 311 def ignorableWhitespace(self, content):
>
> /usr/lib/python2.4/site-packages/_xmlplus/sax/saxutils.py in
> writetext(stream, text, entities)
> 186 def writetext(stream, text, entities={}):
> 187 stream.errors = "xmlcharrefreplace"
> --> 188 stream.write(escape(text, entities))
> 189 stream.errors = "strict"
> 190 else:
>
> /usr/lib/python2.4/codecs.py in write(self, object)
> 176 """ Writes the object's contents encoded to
> self.stream.
> 177 """
> --> 178 data, consumed = self.encode(object, self.errors)
> 179 self.stream.write(data)
> 180
>
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 54: ordinal not in range(128)
> --
>
> I couldn't found any post about that...
>
> Any idea? Im a real noob in unicode things.
>
> Thx a lot in advance,
> Saik
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
multiple "views" in newforms-admin
Hi all,
I'm wondering if this is seems like a feasible additional feature to
the newforms-admin branch.
Currently I have a lot of very similar models, representing people
roles. They all have addresses, phone numbers, etc, which was easy
enough with subclassing models back in the day. However, even then it
seemed like I kept adding types of people, and that didn't really
scale. What I really want is one "person" that can perform a variety
of roles. Trick is, how to manage this in admin :)
So, I can use managers to control these types of people differently
and I'm wondering how hard it would be to have the admin use *only*
the manager that I specify. Here's roughly the syntax I was thinking
of:
class PoliceManager(models.Manager):
def get_query_set(self):
return super(PoliceManager,
self).get_query_set().filter(role__exact=Police')
class FireManager(models.Manager):
def get_query_set(self):
return super(FireManager,
self).get_query_set().filter(role__exact='Fire')
def total_saved(self):
return sum([x.total_personal_saves() for x in
self.get_query_set()])
class Person(models.Model):
blahfield...
role = models.CharField(editable=False)
police_force = PoliceManager()
fire_response = FireManager()
def save(self):
# set appropriate role?
class PoliceAdmin(admin.ModelAdmin):
admin_name = 'police_force' # defaults to model name
manager = 'police_force' # must match Manager name in
model, defaults to 'objects'
list_display = ('blah1', 'blah2')
class FireAdmin(admin.ModelAdmin):
admin_name = 'fire_response'
manager = 'fire_response'
list_display = ('blah1', 'total_personal_saves')
admin.site.register(Person, PoliceAdmin)
admin.site.register(Person, FireAdmin)
admin.site.register(Person)
Which would result in three admin lists displayed (according to
admin_name): 'Fire Response', 'Police Force' and 'Person'. I haven't
really figured out how "add" would work yet (i.e. the role would need
to be known and set somehow), but I think I just need to try a few
things out.
I hope this is not completely muddled. I'm not certain it is the right
design solution (although, as I said I have several "types" now and
they seem to be increasing in number) but first I need to know if this
would be a relatively easy change to newforms-admin. Also I'm
interested in what others think about this so let me know.
-rob
--~--~-~--~~~---~--~~
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: multiple "views" in newforms-admin
So after a little while of looking around, I have come up with two
conclusions:
1) It seems quite simple to add that functionality; and
2) The model design I suggested doesn't fit as well as what I have now
done, which was to add an extra related model to manage the most
common pieces
So there you go! Perhaps someone will come up with a really compelling
case to add it, but it probably won't be me.
-rob
On Apr 19, 12:58 am, oggie rob <[EMAIL PROTECTED]> wrote:
> Hi all,
> I'm wondering if this is seems like a feasible additional feature to
> the newforms-admin branch.
>
> Currently I have a lot of very similar models, representing people
> roles. They all have addresses, phone numbers, etc, which was easy
> enough with subclassing models back in the day. However, even then it
> seemed like I kept adding types of people, and that didn't really
> scale. What I really want is one "person" that can perform a variety
> of roles. Trick is, how to manage this in admin :)
>
> So, I can use managers to control these types of people differently
> and I'm wondering how hard it would be to have the admin use *only*
> the manager that I specify. Here's roughly the syntax I was thinking
> of:
>
> class PoliceManager(models.Manager):
> def get_query_set(self):
> return super(PoliceManager,
> self).get_query_set().filter(role__exact=Police')
>
> class FireManager(models.Manager):
> def get_query_set(self):
> return super(FireManager,
> self).get_query_set().filter(role__exact='Fire')
>
> def total_saved(self):
> return sum([x.total_personal_saves() for x in
> self.get_query_set()])
>
> class Person(models.Model):
> blahfield...
> role = models.CharField(editable=False)
> police_force = PoliceManager()
> fire_response = FireManager()
>
> def save(self):
> # set appropriate role?
>
> class PoliceAdmin(admin.ModelAdmin):
> admin_name = 'police_force' # defaults to model name
> manager = 'police_force' # must match Manager name in
> model, defaults to 'objects'
> list_display = ('blah1', 'blah2')
>
> class FireAdmin(admin.ModelAdmin):
> admin_name = 'fire_response'
> manager = 'fire_response'
> list_display = ('blah1', 'total_personal_saves')
>
> admin.site.register(Person, PoliceAdmin)
> admin.site.register(Person, FireAdmin)
> admin.site.register(Person)
>
> Which would result in three admin lists displayed (according to
> admin_name): 'Fire Response', 'Police Force' and 'Person'. I haven't
> really figured out how "add" would work yet (i.e. the role would need
> to be known and set somehow), but I think I just need to try a few
> things out.
>
> I hope this is not completely muddled. I'm not certain it is the right
> design solution (although, as I said I have several "types" now and
> they seem to be increasing in number) but first I need to know if this
> would be a relatively easy change to newforms-admin. Also I'm
> interested in what others think about this so let me know.
>
> -rob
--~--~-~--~~~---~--~~
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: Always loaded tempalte tags?
In 0.92 you could do this:
@defaulttags.register.simple_tag
def my_tag():
pass
Without looking (and probably regretting my laziness...) I'm guessing
the same is still available.
-rob
On Apr 24, 8:38 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> As someone who works with the Django template language eight+ hours a
> day, I've built up quite a library of tags and filters that I use a
> LOT. Like, in nearly every template. For example, I pass almost every
> bit of text through a filter that applies Smartypants formatting (for
> proper quotes and other typographical goodness). As you might expect,
> nearly every template I create starts with the same three {% load
> %} tags. I find this annoying.
>
> Is there some way to add a template tag library to those that are
> loaded at all times? If not, should there be? I'm all for only loading
> what you really need, but I sincerely do need certain tags and filters
> to be available at all times. Is this possible?
>
> Thanks, guys!
>
> Jeff
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Extending admin interfaces
Hi, I've been modifying admin interfaces lately and I've found a few restrictions that we might be able to avoid. I think this could make the admin interfaces much more flexible. Why admin, you might ask, instead of just creating custom views? Well, if you look at how much you get for free, there is no question. The ability to add and select new foreign key references, the ManyToMany fields, all the validation - pretty slick! Here are what I think are the biggest problems: a) URL redirection is not easy and quite limited. This could be a problem if, say, you have a custom view for something and want to send somebody to the admin interface to enter an object. b) You cannot easily add extra form fields or extra output. These might be needed if you have complex relationships between classes or want to limit the fields that are displayed (beyond what you can do with edit_inline). Also I think we should consider how much this affects the user experience. The admin interface blows your socks off when you see it for the first time! But when it comes to customizing (beyond what META offers, and the excellent template system) it becomes quite a roadblock. Solving the problems above could make that customization much easier. So, in order to fix those two problems, I have some suggestions: 1) Put the redirect info in a Manipulator class. This could be optional with getattr() methods 2) Decouple the Manipulator's formfields from the opts class. Again this could be optional. This could allow for Manipulators to be distinct from the model - quite nice if you have different ways to view the same table. Perhaps this isn't a necessity if you copy and override the opt field. 3) Allow for easily overridding the field loading/saving behaviour. 4) Allow for additional context info in the add_stage/change_stage render methods I figure 1 and 4 are pretty easy. The rest is a bit more complex - I wasn't able to get very far. FYI, the way I've been using the Manipulators is the following: class EditPollManipulator(polls.ChangeManipulator): def __init__(self, object_id): polls.ChangeManipulator.__init__(self, object_id) def flatten_data(self): d = polls.ChangeManipulator.flatten_data(self) # d['previous'] = 50.0 return d def edit_poll_test(request, app_label, module_name, object_id): #manip = polls.polls.ChangeManipulator(object_id) manip = EditEnrollmentManipulator(object_id) #main.change_stage(request, app_label, module_name, object_id, manip) But I have yet to really get this to work. Do these changes make sense? -rob
Re: save/delete/etc hooks for custom fields
An event system is a great idea! If we could tie it into AJAX there are some pretty amazing things that we could do. -rob
Re: Database querying in Django
Yes, it is a little ugly. I would suggest that you put the Q arguments outside of your query for readability (also for those 'subqueries' you were talking about): hello = Q(headline__startswith='Hello') bye = Q(headline__startswith='Goodbye') articles.get_list(complex=(hello | goodbye)) As usual, it is more than just the syntax but also the coding style that makes some code ugly or not. Maybe the examples should be updated, so they don't look so abrasive. -rob
Re: Subquery support in DB lookup
I think the biggest criticism to an idea like this is that it introduces a lot of complexity without solving all the problems you need to solve. For example, what if you need to form a join with another table that goes beyond polls_choices. An alternative is to generate some other function that directly calls the database - and you can do that currently (cursor.execute). The only downside is that it is not database-agnostic, but considering the limited number of times this is required that seems like a reasonable cost. I think at some point we go beyond that area where flexibility and simplicity are both in harmony, and IMHO the syntax above is an example. Having said that, there are some useful and very common operations that we should support. You could have used one of them - poll.get_choice_count() - there may be some others that are both simple to use and commonly used. For one, I think "sum" might fall into that category. -rob
svn eol-style
Hi all, I'm a little embarrased to ask... I am working off Win2K, and any time I open a file with notepad (which doesn't convert line endings) I'm looking at a *nix file. Also any change I make to my local copy results in full-file diffs. Is it possible that some (read: all, or almost all) files in the SVN repository need to have the eol-style property set? It has been hard to figure this out (me being new to SVN and all), but from what I understand, these should be "figured out" when I talk to the server but only if the eol-style is set correctly. Am I off the mark here? -rob
Re: svn eol-style
Thanks John. So even with a good editor (I'm a SlickEdit guy myself) it can cause problems when you diff saved files if you don't happen to change the default editor save behaviour. Should I open a ticket? -rob
Re: svn eol-style
FYI here are the 'text' file endings that are used throughout (if you used autoprops in your config file you would set these to eol-style:native): .css .html .js .po (?) .py .txt And here are the binary ones (which you wouldn't include in the autoprops): .gif .mo .png That only works for adding/importing new files, though. As for setting them currently, one possible way is to recursively set the values to native, then go to those directories that have binary files and use propdel. But as I said I'm new to svn, there is probably a better way... -rob
Re: "Magic" model module change proposal
Since we're looking, is there some way to more clearly separate table vs row than using pluralization? e.g. I think it would be much cleaner if we could say something like rec = Poll() table = Poll.table() fewer imports required, less misspellings, etc. Don't know if it would be possible, though... I am new to Python and know there is the 'classmethod' option but don't know if there are other details to consider. -rob
Re: "Magic" model module change proposal
Ignore my earlier post. I prefer Robert and Hugo's thoughts on this - even as a newcomer :) -rob P.S. AFAICS, removing the magic class behaviour is much more important than the changes that were originally proposed
Re: svn eol-style
Can somebody with checkin privs do this? I think the info I posted earlier will work (followed by a commit, of course): at top level of a clean checkout: svn propset snv:eol-style native -R . cd contrib/admin/media/img/admin svn propdel svn:eol-style -R . cd - cd conf/locale svn propdel svn:eol-style -R . svn commit John, you might be able to correct some of this! -rob
Re: Removing the magic
How will 'or' queries work in the new get_list syntax? -rob
Re: Descriptors for fields?
I would still avoid pluralization, if that was implied. Also you would
need to add "count", "values", "bulk" etc but that seems natural enough
from your suggestion (e.g. reporter.articles.count)
So by implication you could filter on the reporter object also? e.g.
reporter.filter(first_name__startswith="John").order_by("last_name")
I have to say, though, this just seems like another way to "paint the
bike shed". Perhaps we should look at this by saying first "What is
missing from our current implementation?" or "What is difficult?" The
first few parts of the removing magic wiki make sense - adding
properties, allowing for easier overloading of model behaviour, etc.
Much of the syntax discussions that have been occurring since then have
not deliberately solved many problems (except perhaps readability).
If we want to really criticize the query syntax, we should start with
these issues:
1) Limited join capabilities
2) Complicated "or" syntax
3) Limited aggregate functions
If we can solve some of these problems AND come up with a "cleaner"
syntax, then we've achieved what we need. Otherwise, we're just
paintin'!
-rob
Re: Descriptors for fields?
> This makes about as much sense as "The police shouldn't fine me for speeding when they could be out catching murderers." That we have other features required doesn't mean we are not allowed to think about this one. My point is (as well as trying to improve the query capabilities) that if we are going to change the query syntax we should also improve the query capabilities. The ideal syntax would be extensible (I think your suggestion is more extensible than the current query, for example) as well as clear and easy to use. I'm not saying it can't be done with what you have proposed, but I think extensibility should be the primary goal of changing the syntax, and the secondary goals should be clarity/readability and ease of use (knowing that currently these things are OK, just not great). -rob
Re: pluralization - was Re: Descriptors for fields?
The "len" idea is not great anyway - it is much more costly to get and len 10,000 rows than to use SQL count, as get_article_count does. -rob
Re: pluralization - was Re: Descriptors for fields?
Right, but what good is overriding len(..) if you have the list already? You've already fetched the records, right? As Jacob said before, when you say "get_article_count", you know that you are actually executing an SQL query. What is the case when you say reporter.articles? Is this a list already (from cache or from an SQL execution)? -rob
Re: pluralization - was Re: Descriptors for fields?
Okay. Sorry that wasn't intuitive to me. -rob
Re: Admin URLs in magic-removal branch
Would it be possible to override the url location within the modules/classes? My only concern is that sometimes the project, module and/or class name are not an appropriate part of a URL, and would be nice to easily override. (This of course assumes that URLs are part of the UI, which I feel is true.) -rob
Re: Admin URLs in magic-removal branch
Sure. There may not be a need for a "project" dir when you have only one project running. It is cleaner to simply have /admin/blog/entry/add or even /admin/entry/add. Also, you may want your model to technically describe the object accurately, but present it to the user in a more readable way, or for the sake of programming ease use shortened names for the model e.g. UserPrefs which might turn into '/preferences'. Of course, this should all be optional as usual. I figure you could pretty simply use a reserved property or method in the module or class, something like __adminurl__. -rob
Re: magic-removal q
Can the admin options be specified in the meta.Manager field? e.g. class Whatever(Model): name = CharField(maxlength=100) objects = Manager(list_display=) -rob
Re: magic-removal q
Robert Wittams wrote: >That would be even wierder in my opinion, as the Manager: >a) is not required >b) is orthogonal to the admin Fair enough. I guess what I was looking for was an ADMIN class that is closer to a manipulator (and if so I think it is inflexible to assume there should only ever be one ADMIN class per model). However I realize I'm reflecting on the complexity of using manipulators in general, and was probably looking to overload the ADMIN functionality too much to solve that problem. -rob
Re: Removing core fields (and a new edit-inline interface)
> Questions? Comments? Concerns? One comment: something that has been bugging me for a while is the location where you specify the inline behaviour. For example (using the Poll/Choice models): class Choice(meta.Model): poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED, num_in_admin=3) Specifying the view for a related table here seems fundamentally wrong! For clarity I think it would be cleaner to specify in the Polls META classes: class Poll(meta.Model): class ADMIN: # or whatever the new syntax is! fields = ['field1', 'field2'] inline_elements = (['Choice', meta.STACKED],) class Choice(meta.Model): poll = meta.ForeignKey(Poll) Not sure if this is related to what you're working on, though. -rob
Re: Removing core fields (and a new edit-inline interface)
Jacob says: > I kinda think it should be:: > > class Poll(Model): > ... > > class Choice(Model): >poll = ForeignKey(Poll) > >class ADMIN: >edit_inline_on_relation = 'poll' But in (almost?) all other ways the admin section represents the view for the current model only. And what we are saying here instead is that it represents a view for a different model. Anyway, it's not really a big deal. Getting it out of the field definition is a good move, regardless of which Admin class it goes in. -rob
Re: Removing core fields (and a new edit-inline interface)
Jacob says: > Yeah, I don't think I explained myself well enough; let me give a concrete > example of why I'd like this: Thanks, Jacob, it helps to see things from other perspectives and especially in that case I agree the gains are well worthwhile. I was thinking also about how this might work with different views of the same model. Right now the admin interface is very rich but we can only have one interface per model. If there was ever a move to make multiple admin views (or stated more correctly, to make admin an extensible interface for form-manipulation operations), then this design doesn't fit quite as well. However, there are other potential solutions to that particular problem (if the need for it ever arises) and we could deal with it then. -rob
Re: Proposal: Allow custom redirects in the admin system
> Another option would be to have the callable return a (url, message)
tuple, and let the view handle HttpResponseRedirect and
request.user.add_message.
I think you should use a dictionary. For example, you could pass in the
following dictionary:
{None:'../report1/%s'}
and then in the default method:
else:
request.user.add_message(msg)
redir = redir_dict.get(None, '../../')
return HttpResponseRedirect(redir)
etc. for all types of POST in the method.
Anyway, you could pass this into the change_stage method via the admin
class, or via urls.py (which is how I'm using this technique).
('url1/', 'change_list', {'app_label':'myapp', 'module_name':'mymod'}),
('url1/\d+/', 'change_stage', {'app_label':'myapp', 'module_name':
'mymod', 'redir_dict':{None:'../report1/%s'}}),
('url1/add/', 'add_stage',
{'app_label':'myapp','module_name':'mymod','redir_dict':{None:'../report1/%s'}}),
or you could write a tiny custom view that does the same and looks
cleaner!
Of course you could throw the same dict into the admin class to achieve
the same.
The reason I think it is nice to do this without a custom
"after_change_action" method is that much of the after_change_action
code would be duplicated on different modules, but the actual url is
the part that changes. Also much of the time you will just want to
redir the "Save" action and none of the others.
-rob
Re: Proposal: Allow custom redirects in the admin system
> Also, I don't believe post_url would allow you to use something like
the new object id in your url.
I needed this capability (I have wizard-like interfaces derived from
the admin pages), and ended up modifying change_stage so it read
something like this:
redir = redir_dict.get(None, '../../') # actually I just used a
post_url arg like in add_stage
if redir.find('%s') >= 0:
redir = redir % pk_value
return httpwrappers.HttpResponseRedirect(redir)
and I pass in post_url strings like '/report1/%s/'
Still this only works in simple situations (e.g. you cannot derive
other info from the POST like perhaps a date field as well, to format a
url like '/report1/123/2006/01/') so I think there is still value in
custom after_change_action methods.
-rob
Re: Using an inner class for custom Manager in magic removal branch
> I suppose the greater problem is the ability to easily construct (and use) a filter on queries (e.g. construct a 'tall_people_only' filter, make it a member of Person, so you can write Person.get_list(tall_people_only, name__exact='Fred'). You should be able to do this using arg-level query objects (see ticket #1133) - it sounds like Robert's descriptor queries will make this sort of thing even easier. Actually I think the problem is two-fold: the admin interface is too good and the manipulator API is too poor! I think trying to use multiple managers seems like a specific solution to a broader problem. What happens when you need a manager to span multiple models? It breaks down there. I don't have any real alternative suggestions - sorry. I've been extending the (0.91) admin interfaces as much as possible and my biggest struggle has been these issues - things like limiting the fields based on user, adding only certain fields from related models, which differs between models, etc. I think the bigger issue is divergance of manipulators and the admin managers. If these were more interchangable (i.e. the Manager merely being a "shortcut" to dealing with templates and manipulators, rather than a completely different tool from manipulators) I don't think these issues would come up. -rob
Docutils link in admin interface
Maybe it's just me... Why in the world would we want development documentation in the admin interface? I noticed that the "Documentation" link was added to the user links section, but none of the users of any real world application I can imagine would benefit from that documentation. Even having the "doc/" reference in the admins.url file is pointless, IMHO, and I don't like putting extra details about implementation in the user interface. If anything, it could be triggered by DEBUG=True, or another field in the settings.py file, but I think we should avoid telling people anything more about the application than is necessary. -rob
Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)
> It's not just the referential integrety - even though that's complicated enough, with ISPs not allways installing newest versions of databases - but the .delete() overloading, too. If your class overloads .delete() to do specific stuff, that code will not be called when you do bulk deletes. Doesn't the delete function also checks permissions on all the referenced rows? I don't think you can implement this in SQL. Frankly, the bulk delete seems to have some problems with usability, too. I've deleted objects that have somewhere around 20 or 30 references and the screen it filled. If I was trying to delete in bulk, it would be unusable. I think it would be better to treat a "bulk" operation differently from the regular one, somehow. For example, I would suggest an extra "can_bulk_delete_model" permission, and instead of showing all the related objects in the confirm delete screen, just show the parent objects themselves. This would avoid confusion with "custom" delete functions because those functions would never be called. -rob
Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)
I said: > Doesn't the delete function also check permissions on all the referenced rows? I tested this and found a bug (#1250), but I confirmed that you cannot delete items through the admin interface if you don't have delete permissions to ALL related objects. -rob
Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)
> You are talking about the admin interface - we are talking about the database > API. The database API doesn't check any permissions, as it's a Python call > done by the programmer, and we still trust the programmer ;-) Yep, I realize that, and wasn't trying to ignore the db changes to support this. I just wanted to consider that cascading deletes would not necessarily work through the admin interface with the current permissions and lack of "confirm" behaviour. -rob
Re: Congrats on great framework
> of course django is still much much better than any java framework :) I know this thread has gone off topic, but I couldn't resist :) I've been looking a lot at enterprise offerings lately and have been thinking about these issues. After several failed J2EE attempts, Django has always looked very promising. Here's what I think are the obstacles to using J2EE that usually don't apply if you use Django: 1) Very long timeframe for development, especially the planning phase. Not only does this increase the risk of schedule failure, but also allows for "corporate restructuring". In almost all cases that I was involved with, the J2EE investigation/almost-project got canned because by the time we were ready to ramp up development, it was decided that our customers didn't need a server-based solution so we quit early on. Of course, a J2EE project requires a *lot* of planning, so this was inevitable. With Django, however, you can show (production) results very quickly - I don't think we would have had the same results. 2) Lots of initial work for minimal return. J2EE pays off a little more after you have your initial framework in place. 3) Resistance to change. It is pretty hard to make significant changes to a J2EE project, but is usually a breeze with Django. Overall, I think many projects are looking at an order of magnitude saved with planning, design, development and testing using Django compared to J2EE. So there is a lot going for Django over J2EE. But I think there are still some reasons that people are considering J2EE instead of Django (apart from legacy application support), for example: a) Perception: still people consider that Django cannot handle high loads, and thus not considered "enterprisable". I don't know if there are any tests that directly compare a J2EE project with a Django project, but I'm pretty sure the overall results are similar. There are scalability options within Django that should work fine, as far as I understand (e.g. separating databases when they reach a certain size). Anyway, to improve perception of Django's capability, I think numbers would help. b) Distribution: most J2EE apps are pretty easy to wrap in an InstallSheild application and can be sold as an application. This fits a product business model (who just want to sell a product and be done with it) rather than a service business model. Ideally, Django would be used in a service business model, so that updates occur more frequently and naturally, but with a little work I suppose it could be sold as an application. If anybody has sold a Django application (as a package instead of a service), it would be good to get some information on the website. c) Project development: using Django implies a different approach to creating projects (as I suggested, probably a lot less time planning, for starters). An example project structure on the website would probably help explain the process a little more. Even better, a real-life project structure, if possible! d) Testing: J2EE developers expect that the containers they use have passed some sort of product testing. I know Django has some unit tests, but I'm not sure if anybody has done system testing (or if so, at what stage in development). That would certainly help to show how far along development is (I think people still baulk at the pre-1.0 version). Again, numbers would help here. Analyzing, properly prioritizing and reporting the open bugs can show how stable the tool is. Alright, I'm done with my rant :) -rob --~--~-~--~~~---~--~~ 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: Deadline Driven Development
Although I normally encourage plenty of formalization, I don't think this is a good idea right now. Here's why: 1) The deadlines referred to in documentation are for a small team with money coming in. Django is a larger "team" (meaning lots of input from various interests) with no money as a direct result of their work. Don't hold them to the same expectations! 2) The contribution team is rather small and actually communicates a lot amongst themselves. Even if it is not all that clear what state we are in, I think they have a pretty good idea of things. 3) Merging magic-removal will destabalize the trunk for a while. Its hard to get accurate estimates from there. 4) There is already some planning on the wiki. Basically the only thing that is missing is number 2 from above - the release deadline date. I see the desire you have for a concrete date to rely upon, but consider the cons of a deadline - quality is now a variable standard. I've seen plenty of projects pushed out with poor quality because of this, and deadline driven development leaves a bad taste in my mouth. Please lets wait a month or so and reevaluate this option. I think by then it will be much easier to get a solid handle on what should be in 1.0 and when would be a good date to aim for. -rob --~--~-~--~~~---~--~~ 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: browser caching of the admin
> Opinions? I'll go ahead an implement this if no-one screams. I'm a little concerned that you found this - I deployed a similar app several months ago and have not heard of a single case of this. (I'm using rev 1764.) Are you sure that changing Django will fix this? If you only found it when you switched (and now hearing that it may not be a universal problem), I would recommend some more environmental diagnosis at least to understand the situation. As for the solution, it makes sense to give some more flex to the caching system... -rob --~--~-~--~~~---~--~~ 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: browser caching of the admin
> I'm not sure if I can really spend any more of my company's time diagnosing this problem! Certainly the change has worked, and could be useful for anyone in a similar situation. No worries. This helps! I'm going to look out for something like this as well now, and will probably need to patch with your changes. It is somewhat likely the proxy is involved in the behaviour - not that I'm aware of a specific caching feature in any proxies out there but (after I just finished 5 years of working on routers) it does sound like a likely "feature" candidate. I think this would affect a lot of other (than Django) web applications as well. Should this decorator be added to the generic views? I can see arguments either way. Perhaps it is safer to come up with a different generic view (or a parameter) if you never want to cache? I would also suggest we add a comment to the Forms documentation to recommend using this decorator. Good find! -rob --~--~-~--~~~---~--~~ 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: Think about urlconf again
> So we want to think about if the app_pefix can be easily changed or remapped.
Can't you just use "include"?
urlpatterns = patterns('',
('^%s/' % app_prefix, include('app.urls')),
)
Pretty flexible, pretty simple, and already there!
-rob
--~--~-~--~~~---~--~~
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: More specific CSS rules for the admin
> I'm open to being convinced otherwise, but I don't see it as within the scope
> of the admin CSS to accomodate being embedded in other interfaces.
Not to throw fuel on the fire, but for some applications in particular
we're stuck between a rock and a hard place, and the admin interface is
the simplest answer.
I believe I have an application similar to Chris's - I use the admin
interface as a "basis" for most of the interactions that my customers
choose. The reason that I did this was:
1) Most of the objects I have are fairly simple but fairly long. Why
not have these autogenerated?
2) The "important" parts of the application run in a wizard-like way.
Basically all I have to do is control the order of admin interfaces and
my work is done.
3) The user/group/permissions system is adequate for my needs
4) Read-only views and editable overrides can be easily created to look
like other admin pages, so they are consistent
5) Writing forms is a real bear. This is of course the biggest problem.
So while I don't propose that the admin interface should be the answer
to everybody's problems, sometimes the choices are limited. What's
funny is that I think the problems of forms (and the need to use the
admin interface) is the biggest limitation with Django right now. I
could care less about magic removal! Unfortunately I don't have a good
solution to the forms problem, but I've been working on it.
Personally I don't have Chris's problem. However I did make one change
to accomodate my needs (not that this will solve Chris's problem):
--- contrib/admin/templatetags/admin_modify.py (revision 1764)
+++ contrib/admin/templatetags/admin_modify.py (working copy)
@@ -234,7 +234,9 @@
change = context['change']
class_names = ['form-row']
+id = None
for bound_field in bound_fields:
+id = 'row-%s' % bound_field.element_id
for f in bound_field.form_fields:
if f.errors():
class_names.append('errors')
@@ -249,6 +251,7 @@
'change': context['change'],
'bound_fields': bound_fields,
'class_names': " ".join(class_names),
+'id': id,
}
admin_field_line = register.inclusion_tag('admin/field_line',
takes_context=True)(admin_field_line)
Index: contrib/admin/templates/admin/field_line.html
===
--- contrib/admin/templates/admin/field_line.html (revision 1764)
+++ contrib/admin/templates/admin/field_line.html (working copy)
@@ -1,5 +1,5 @@
{% load admin_modify %}
-
+
{% for bound_field in bound_fields %}{{ bound_field.html_error_list
}}{% endfor %}
{% for bound_field in bound_fields %}
{% if bound_field.has_label_first %}
Note the quite old revision.
I would say to Chris - for now, at least, just make changes in your
working copy.
-rob
--~--~-~--~~~---~--~~
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: More specific CSS rules for the admin
> My point is not that you should or shouldn't have to write your own form > code. My point is that (in my mind anyway) needing to write your own styles > is not a barrier to reusing the admin form code. Yes, I agree. Like I mentioned, the only limitation I've faced with the styles that come with admin is the one that I mentioned above - I consider this a unique customization rather than a general need. > Styling forms (once) is a lot less tedious than writing them (over and over). > And style is something that ought to be unique to each site (at least on the > public side). Personally, I don't want to see a lot of Django sites out there > that all look like they came from the same template. Also agreed. Very easy, too! The completeness and customizability of the admin framework is a really attractive feature of Django. -rob --~--~-~--~~~---~--~~ 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: More specific CSS rules for the admin
> Take zyons.com for example, a open source forum app I'm developing. I grabbed > the admin template modified it slightly and pushed it out. zyons.com is about the level of admin L&F customization that I was thinking about - tweaking CSS & templates just a little. Even just colors. -rob --~--~-~--~~~---~--~~ 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: Simplify admin template overrides
I would rather see some ability to add variables when render_to_response is hit. In other words, rather than using the proposed mechanisms above to create a unique template, I think it would be more usable if you were to say: def my_admin_override(request, ...): context, template_list = do_most_admin_things() # our custom overrides - e.g. extra variables or operations return render_to_response(["mytemplates/%s/change_form" % ops.object_name.lower()] + template_list, context_instance=context) There was talk of processors that could possibly/probably do a cleaner job than this - not sure where these stand. -rob --~--~-~--~~~---~--~~ 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: Request dispatch based on http method/url
> What is the best way to dispatch to a method based on both HTTP method *and* > a URL? Basically you've found it, and it is a clean way to code. However you have to consider calling get_myresource() from post_myresource(), as you would probably do if the POST has errors. Typically manipulators are used to initialize variables in the GET function, but if called from the post function you would NOT want to re-initialize the vars. What you could do instead is simply add an optional parameter to the GET function so you can pass in the already-initialized variables as needed: def get_myresource(request, param_dict=None): if not param_dict: # initialize from manipulator display def post_myresource(request): You could also very easily make the myresource() method generic, and take an argument from URLConf. Something like: def dispatchview(request, viewname): method_type = request.POST and 'post' or 'get' method = getattr(views, '%s_%s' % (method_type, viewname)) return method(request) -rob --~--~-~--~~~---~--~~ 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: Oldforms-admin to Newforms-Admin helper script
> Would this be useful enough to include in django itself? This could be posted somewhere on djangoproject.com or djangosnippets.org. I wouldn't recommend using the management commands - this is a one-off operation and there's no need to change django itself (besides, people will probably want to do things slightly differently with the results). However, I do think it would be appreciated. -rob --~--~-~--~~~---~--~~ 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: obscure import error(s)
On Sep 14, 3:28 am, HenrikV <[EMAIL PROTECTED]> wrote: > Where should I look to catch exceptions in application models ? Don't use manage.py, instead set DJANGO_SETTINGS_MODULE and PYTHONPATH and start a regular python shell, then import some apps (i.e. comments app) separately. As far as how this fits into django, my suspicion is that you've got multiple django installations going. However, if you can narrow down the cause (and it comes from just one django installation), it is probably worth logging a ticket. -rob --~--~-~--~~~---~--~~ 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: django.forms.SafeForm - forms with built in CSRF protection
On Sep 22, 1:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote: > CSRF[1] is one of the most common web application vulnerabilities, but > continues to have very poor awareness in the developer community. > Django ships with CSRF protection in the form of middleware, but it's > off by default. I'm willing to bet most people don't turn it on. > > I don't believe middleware is the right way to approach this. It's too > "magic" - it involves code that parses and re-writes your HTML as the > response is being returned. It also means CSRF failures can't be > gracefully handled - the middleware can throw up a big ugly error > page, but ideally a CSRF failure would be treated the same way as a > regular form validation error. I just read this thread now, and by the end of it, things are looking pretty complicated. Is it worth a gut check to make sure this is worthwhile? Although the middleware might be a hack now, it seems sensible that it fits in request/response areas rather than in forms: you still need to go out of your way to add it anyway (so users won't necessarily "turn it on"); it takes a lot more code; add in the multiple forms per page question, and to me it seems like you've fixed a problem by introducing another. Finally, it doesn't take much to make a pretty message - something like "You are under attack, close down your browser and try again" with images of flaming people & such - for the (lets be realistic) very rare cases when a CSRF attack occurs. All you need is a template, right? (And I would consider sending an email to the admin notifying them that at attack was attempted, at least to get an idea of how common these issues are.) -rob --~--~-~--~~~---~--~~ 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: django.forms.SafeForm - forms with built in CSRF protection
On Sep 23, 3:26 am, Simon Willison <[EMAIL PROTECTED]> wrote: > On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote: >> Is it worth a gut check to make sure this is worthwhile? > > Here's a useful case in point: the admin. Django's admin should ship > with CSRF protection turned on and baked in. Right now, I'm willing to > bet 95% of the Django admin sites out there are exploitable via CSRF > because the middleware wasn't turned on. This is really bad. > I'm sorry, I used the wrong term here. I didn't mean that CSRF protection isn't worthwhile, just that going the route of an extended form might not be the best way to do it. As for suggestions, I'm not sure I have one exactly, but I'm thinking of perhaps overriding is_valid() and maybe using the RequestContext object.. not sure yet. -rob --~--~-~--~~~---~--~~ 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: django.forms.SafeForm - forms with built in CSRF protection
> in fact, it takes us back to the > original proposal of a SafeForm that just takes the request object as > an argument to its constructor. Well this seems much simpler, although there is still the requirement to add the csrf_fields whenever you write out the form in the template (which isn't much - I'm just looking for the shortest and most failsafe path). As for making a subclass - is there a problem having "request" as an optional field in the BaseForm constructor? It could then at least be included with as_table, etc automatically at the cost only of adding an extra constructor parameter to existing forms, and ignored without it. -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
unique_for_ fields
Hi all, unique_for_date (and for_month, for_year as well) are not functional in 1.0, but before I try to get them working, I'm wondering if there is any thought about those fields. Currently they are included in the model field definition, but of course the documentation mentions that it is used for validation only at the "admin-form level". Is there a plan to either provide model- aware validation (hmm, that does sound familiar...) or deprecate these options and move them to the ModelAdmin class? Or if there isn't a clear path, what are the recommendations? (It seems like a pretty handy feature so I think it should be reinstated.) There is a ticket open on this: http://code.djangoproject.com/ticket/8377 -rob --~--~-~--~~~---~--~~ 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: unique_for_ fields
On Sep 28, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Short version: model-aware validation is being worked on. We didn't get > it finished for 1.0, but it's still ongoing work. Great! Judging by the activity this is tracked in #6845 so I included a note and a reference in the ticket (and will wait instead of trying to fix it now). -rob --~--~-~--~~~---~--~~ 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: Customizing notification method for internal server errors
Did you try subclassing list (& overriding __iter__) for the ADMINS
object?
-rob
On Oct 15, 1:58 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> The built-in behavior for
> django.core.handlers.base.handle_uncaught_exception calls mail_admins
> for each internal server error.
>
> So if a very high-traffic view has an internal server error, duplicate
> emails will be sent at a very high rate. This isn't usually
> desirable...
>
> We worked around this by changing mail_admins directly in our copy of
> Django to store the last time an email was sent on the filesystem and
> avoid sending multiple emails in too short of a time interval. But it
> seems like there should be a better way to customize this without
> having to modify Django.
>
> I suppose one could define a mail_admins replacement in our app and
> assign it to django.core.mail.mail_admins. But that's rather hacky...
>
> Also, BaseHandler says that handle_uncaught_exception can be
> overridden, but its derived classes ModPythonHandler and WSGIHandler
> are referenced directly in Django, so I don't really see how to
> subclass it without changing the Django code.
>
> I was thinking it would be useful to add a setting like
> EXCEPTION_NOTIFIER = 'path.to.custom.notifier' , where the default
> would look something like this:
>
> def mail_exception_to_admins(request, exc_info):
> from django.core.mail import mail_admins
> subject = 'Error (%s IP): %s' %
> ((request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS and
> 'internal' or 'EXTERNAL'), request.path)
> try:
> request_repr = repr(request)
> except:
> request_repr = "Request repr() unavailable"
> message = "%s\n\n%s" % (self._get_traceback(exc_info),
> request_repr)
> mail_admins(subject, message, fail_silently=True)
>
> Thoughts?
--~--~-~--~~~---~--~~
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: Customizing notification method for internal server errors
On Oct 15, 10:18 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> Is your suggestion that, since mail_admins happens to be the only
> place in Django that uses settings.ADMINS, I could do something like:
>
> class AdminsObject(list):
> def __iter__(self):
> // do some custom notification
> // manually write the friendly 500 error page to the output
> stream somehow
> raise Exception // can't raise StopIteration here or mail_admins
> will connect to the SMTP server
> ADMINS = AdminsObject()
I was hoping it wouldn't be quite that ugly! And just had an empty
list.iter in mind. Something like:
class AdminsObject(list):
def __iter__(self):
if ok_to_send(): # enough time since last mail or whatever
return super(AdminsObject, self).__iter__()
return [].__iter__()
ADMINS = AdminsObject([
('Your Name', '[EMAIL PROTECTED]'),
])
I think your exception would propagate up to the
handle_uncaught_exception and the user would not see the "friendly
error message".
However, after seeing your comment regarding the exception I looked at
EmailMessage and was surprised to see that it attempts to send even
with an empty ADMINS list. It should return if not self.to and not
self.bcc, I think.
> That would be pretty hilarious. Not particularly straightforward or
> maintainable though.
Yes, the got_request_exception signal seems like a better solution as
it gives you more context.
-rob
--~--~-~--~~~---~--~~
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: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
> I agree, and this explanation looks good. +1 Its a bit deeper than that... but I'm waiting for my friend to respond (he worked on sqlite issues at my last company). Hopefully I'll hear from him today and be able to add some more details. -rob --~--~-~--~~~---~--~~ 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: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend
On Oct 27, 11:21 am, oggie rob <[EMAIL PROTECTED]> wrote: > Its a bit deeper than that... but I'm waiting for my friend to respond > (he worked on sqlite issues at my last company). Hopefully I'll hear > from him today and be able to add some more details. Okay, so I got the good word :) First off, I want to acknowledge the work that Ben Cottrell put into finding these issues. It seems like this is usually discovered only with a specific setup and it took a lot of time and effort for him to track down the issues. Essentially you'll need to use pysqlite 2.5.0 for this to work. Even increasing the timeouts won't "solve" the problem, they'll just allay them a little (and at some point you'll see the locks again). Certainly, there is a limit to how quickly transactions can get done with sqlite (and thus the timeout is still relevant), but I don't think you will want to rely on that. The reason pysqlite 2.5.0 works is due to the fix in changeset 337 (http://oss.itsystementwicklung.de/trac/pysqlite/changeset/ 337%3A80ee6488cb53). It is much more likely to be noticed if you're running in a multi-threaded environment (and from what I could determine, this is the reason it hasn't been more of an issue to the django community, given that sqlite is fairly widely used). Also, because django 'prefers' sqlite3 to pysqlite, you'll need to patch django/db/backends/sqlite3/base.py after you've installed it. (This change should probably be merged into trunk as it allows for installing the most recent version of pysqlite, as opposed to whatever sqlite3 you have in your python version. In other words, I think django should "prefer" pysqlite as a more intentional setup.) Finally, one issue we didn't really dig into but Ben did discover, is changing from a shared (i.e. "reading") to an exclusive (i.e. "writing") lock. Example: you're iterating through a queryset, and inside the same transaction you do some write operation, *and* you have threads colliding with each other (both trying to get an exclusive lock), you may see the db locked exception. A simple workaround for this is to force an evaluation on your iterating queryset (i.e. wrap it in list()), or run the write operations after you have finished the iteration. If this looks like a lot of work to get sqlite going, you might be right :) I hope that covers everything. I'm willing to update the ticket, but first do you think you could try the pysqlite fix that I suggested (and remove the timeout change to be certain that doesn't interfere)? I want to be sure that it solves it. -rob --~--~-~--~~~---~--~~ 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: Optional {% default %} clause for the {% for %} template tag
> {% for item in grocery_list %}
> {{ item }}
> {% default %}
> Nothing to buy.
> {% endfor %}
Please, though - use {% else %}. Its totally clear what its referring
to and else doesn't mean squat unless you see what the if (and in this
case, for) test is anyway, so I don't think this would be confusing
(after all, this isn't python).
(Also, if you want to avoid confusion don't use a keyword that is
located within another language's looping construct :)
-rob
--~--~-~--~~~---~--~~
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: 1.1 feature: unify access to response.context in test client
> I'd prefer backwards compatibility. The way I'm envisioning it would > complicate the code a bit, but I think preserving compatibility is > worth it: It would be nice to keep backwards compat, for the sole reason that the quickest way to test your code against a django upgrade is to run tests - it would be ideal to migrate to 1.1 without having to refactor any tests just to get there. OTOH, I don't think it would be a huge deal to not preserve backwards compat - in the worst case scenario, users can simply comment out the offending code temporarily, and although backwards compat is emphasized from 1.0 on I think there would be some leeway with a fairly specific test feature. The worst situation would be buggy test code, so if it turns out to be very complicated to maintain backwards compat, we should leave it behind. -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
more clock increments
Hiya, I thought I would shout out ticket #1848 (30 minute increments in the admin time widget) for inclusion in 1.1, if anyone wants it. I'm still using it and others might find it useful. http://code.djangoproject.com/ticket/1848 -rob --~--~-~--~~~---~--~~ 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: Using pysqlite2 instead of sqlite3 when desired
> Since so far only you and I have made real input here, I'd like to hear > what any of the other maintainers (or anybody else who uses this stuff) > thinks. Realistically, any of the options are survivable, so barring any > great arguments one way or the other, we should just pick one and commit > it. I don't see the functionality request as being controversial and I'm > probably putting too much effort into worrying about the fine details. I've faced issues with sqlite3 before and the biggest issue in my case was simply being aware that using pysqlite was a quick and simple solution to concurrency and db locking issues. So making it explicit wouldn't hurt, for the sole reason that it communicates that concept (assuming of course it is documented :) Since sqlite takes advantage of the DATABASE_OPTIONS field for timeout, it would probably make sense to use # 2. -rob --~--~-~--~~~---~--~~ 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: How do you handle cascading deletes in your production apps?
On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote: > I'm building an application to track IP addresses on many corporate > networks with a single subnet having around 65535 rows for IP > addresses. Now this app has thousands of those subnets which means > I have millions of rows for IP addresses. Rather than simply consider how to delete those IPs, take a close look at your database architecture as a whole. You're looking at db scaling issues across the board. I'm not saying you can eliminate those millions of rows, but its worth a think. -rob --~--~-~--~~~---~--~~ 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: Many-to-many relationships with additional columns
Yeah! This is much cleaner. I need to add ordering to some model relations (i.e. represent all related values as an ordered list, where relations can be shifted up & down) to the M2M field, it looks like it would fit much easier using a manager & concrete Model subclass than being restricted to a field. I don't vote often, but +lots. -rob On May 31, 1:32 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > I've been giving a bit of thought into many-to-many relationships > lately, and I (once again) ran across the task of creating a > relationship that contained additional information. I know this has > been bounced around before, but I can't seem to find any substantial > discussions on the topic, so I wrote up a wiki article[1] with some of > my thoughts. > > I'll be putting up the code I've got working so far that demonstrates > that parts of what I wrote up are indeed possible. The rest should be > as well, but it will probably take some extra discussion and possibly > some patches to how related managers work. I'll deal with that once I > figure out what all would be necessary. > > My main reason for bringing it here, however, is to ask if there are > indeed some previous discussions that I should consider before I go to > far in my experiments on this subject. Or if I'm just completely off > my rocker. > > -Gul > > [1]http://code.djangoproject.com/wiki/ManyToManyManager --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Test response context & template always as lists?
Hi all, Playing around with the test client I found it frustrating that "context" can either be a single context or a list, depending on how the template is rendered. My feeling is they should always return lists. Likewise for the "template" field. I can see that no matter what there is a chance of the test breaking unexpectedly but I think it would happen less & coding would be simpler if those always returned lists. Should I write up a patch for this or is there a benefit to the current approach that I can't see? -rob --~--~-~--~~~---~--~~ 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 1.0?
If you have the time, Mario, you can always create a "django 1.0 release theories" website :) Then all you have to do is come up with some interesting plot twists, some celebrity blogs, and a "find the missing feature" game, and before you know it, 1.0 will be here! -rob On Jul 19, 3:49 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hi Mario -- > > This has been discussed (to death) a number of times. Please search > the archives. > > [Short answer: 1.0 will be released when we can guarantee API > stability. We're not there yet.] > > Jacob --~--~-~--~~~---~--~~ 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: include tag security hole
Perhaps simply by preventing absolute paths? That would be very easy
to change if it doesn't prevent a legitimate setup.
Of course, html coders need to accept a certain responsibility because
sometimes they can access a *lot* of information quite easily. I would
think if you have a non programmer making changes, the programmers
would want to at least review those changes before accepting them, in
addition to a reasonable API.
-rob
On Jul 21, 9:07 am, Czubakabra <[EMAIL PROTECTED]> wrote:
> Hi,
> Include tag is vulnerable to directory traversal:
>
> {% include "/etc/passwd" %}
>
> Django templates shoudn`t permit html coder to include files located
> above TEMPLATE_DIRS paths.
> What do you think about it?
>
> Best regards,
> Czubakabra
--~--~-~--~~~---~--~~
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: include tag security hole
> Sort of, but not really. Personally, I don't think there's any secure > way to allow arbitrary users to upload templates, because there are > just too many ways to expose something you wouldn't want to expose; if > you were going to develop a sandboxed version of the template system, > you'd have to strip it down so much that it almost wouldn't be > recognizable afterward. This was my feeling also, however I think it is prudent to prevent legitimate users from making mistakes. I don't know about designers, but I have worked with some programmers that just don't think things through like they should... You mentioned earlier that you "can see cases where it'd be useful to have it pull in things that aren't in TEMPLATE_DIRS" - I suppose I can also, but everything I can think of is safer & cleaner by restricting it to TEMPLATE_DIRS locations (e.g. adding the extra directories, sym linking, or just maintaining another copy in an existing TEMPLATE_DIRS spot). The advantage is of course that the decision is made by the person managing the settings.py file - which is usually the one who knows more about system security than developers. This isn't foolproof, but does stop some mistakes, and for that reason I think the fix should be included. -rob --~--~-~--~~~---~--~~ 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: include tag security hole
> > This was my feeling also, however I think it is prudent to prevent > > legitimate users from making mistakes. I don't know about designers, > > but I have worked with some programmers that just don't think things > > through like they should... > > This tells me they have a much deeper problem that Django really can't > help solve. ;-) I can always hope for a nice contrib app - one that automatically fires people for poorly written code would probably do the trick! --~--~-~--~~~---~--~~ 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: DecimalField and 'decimal' module.
> > does this also affect psycopg1? > > Looking at psycopg1 code, the answer would appear to be that it is not > affected. Changes to support Decimal appear to be psycopg2 specific. > > Graham The problems I was seeing the other day were repeatable both using strictly psycopg1 (in fact, that was where I first saw the server error). The issue wrt Decimal is that the Django svn version uses Decimal and older versions use float, but because psycopg is "cached" it will convert it into the type that is initialized. In other words, its not psycopg itself - its the fact that it isn't re-initialized between requests. The recommendation I would make for now is that applications using new Django builds should use psycopg2 and applications using older builds should use psycopg1. This way there are two executables that don't clash in any way. I have done this myself and it eliminated all the problems I had with float/Decimal compatibility & Unicode. -rob --~--~-~--~~~---~--~~ 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: DecimalField and 'decimal' module.
> The recommendation I would make for now is that applications using new > Django builds should use psycopg2 and applications using older builds > should use psycopg1. This way there are two executables that don't > clash in any way. I have done this myself and it eliminated all the > problems I had with float/Decimal compatibility & Unicode. > > -rob Forgot to add - this is strictly a temporary solution. If there are any other changes to the backend, this may not work with older versions anymore. -rob --~--~-~--~~~---~--~~ 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: DecimalField and 'decimal' module.
> are you sure this is the same issue? > > from what i saw in the tickethttp://www.initd.org/tracker/psycopg/ticket/192, > > it seems that it can fail even when both sub-interpreters run the same > version of python/django... > > gabor Sorry, gabor I didn't see this earlier. Yes, I'm pretty certain it is the same issue. -rob --~--~-~--~~~---~--~~ 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: choices being a QuerySet or callable
> I was wondering what everyone's stance is on inclusion of something like this. It is not really needed, you can override the field. Take a look at the __init__ call in http://www.djangosnippets.org/snippets/26/ and you can do that with a model field as well as a form field. Yes it is a bit of a pain but you won't need to do it very often, especially since you can use the field again and again (i.e. in different models). Apart from not needing it, a fairly weak reason against including it is that if your query gets large, it becomes unusable (i.e. choices gets too long). Also you might not want to use __unicode__ or __str__ in the choices field but something shorter or more specific to the model that is referencing it. To me it seems more sensible to create a single custom field which you can change in just one place. BTW, it probably would be better to post first in DJ Users. People have worked through problems like this already and have some pretty neat solutions or ideas to some interesting problems. -rob --~--~-~--~~~---~--~~ 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: DecimalField and 'decimal' module.
> Hmmm, I'm not sure how psycopg1 in isolation could be a cause of > problems as it doesn't anywhere in its source code support the new > 'decimal.Decimal' type. Thus, the exact same problem as identified so > far with pyscopg2 couldn't be what was being encountered with > psycopg1. I'm sorry, I should have been clearer. To be honest I would think it were possible to avoid some of these problems by modifying Django somehow, but I haven't looked very closely at how, yet. However I think I do understand how this is happening at present. Let me describe the situation I was in previously and how I saw problems: - Application "Santa Cruz" built with 0.91 using psycopg1. Running for just under a couple of years and accessed regularly. - Application "Curriculum" built with trunk using psycopg1. Added about 2 weeks ago & accessed infrequently. The first problem I saw was when I was doing a (python) sum on a FloatField in the Santa Cruz application. It was saying that it couldn't add Float and Decimal properly. From my very cursory look just now at trunk/django/db/backends/postgresql/creation.py, FloatField is registered as a "double precision" type in the database. However, in 0.91, it is listed as a "numeric(%(max_digits)s, % (decimal_places)s)" - which translates into a DecimalField in the trunk version. So if I visit my Curriculum application, then go to Santa Cruz, I get the error about adding Float and Decimal because the introspection function is "initialized" by trunk. The second problem I saw was more prevalent because it happened much more frequently! After visiting the Curriculum application, a trip to the Santa Cruz application would win me improperly quoted SQL. The reason in that case was because my old 0.91 code wasn't set to translate unicode, and after visiting Curriculum it was returning u'xyz' data instead of 'xyz'. I couldn't even log in! I figure the root cause of both of these problems is data that is accessed in two interpreters, and is propagated by having two versions that expect different results at that point (i.e. 0.91 FloatField instrospection expects a float, not a Decimal). Sometimes it takes a while to be seen, as in my sum call (which I do about once or twice a month, normally). The thing is most of the role of psycopg seems to be kind of like a Singleton or static method object, so it is not always seen, but is obvious when you are using the combinations I was, or the one you reported on the initd site. Conversely, I can see how this hasn't been raised as a major problem before now, since the 'static'-like nature of psycopg doesn't normally show any issues. But I don't like to be the guinea pig and find out how extensively this affects what you can do! > One problem that could arise is if, even in different sub interpreters, > two Django instances separately tried to use version 1 and 2 of pyscopg. > This is because the Python wrappers for one wouldn't match the loaded > C extension module since it is named the same for both versions and > would only be loaded once for the whole process. Are you sure this would happen? If that were the case I would have expected my box to blow up by now. I wonder if the extensions are named differently, or if the namespace avoids the problem (i.e. "import psycopg" vs "import psycopg2")? I haven't seen any problems so far (cross fingers). -rob --~--~-~--~~~---~--~~ 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: DecimalField and 'decimal' module.
> "Curriculum" use psycopg1 or 2? > > seems like that was part of your point. > > Carl K Yeah I didn't mention this post that *now* Curriculum is using psycopg2 and Santa Cruz is using psycopg1, with no apparent problems (sorry, I did mention it earlier but forgot to clarify). But as Graham says, there may still be some subtle risks that I'm unaware. And of course, it won't work beyond two projects! -rob --~--~-~--~~~---~--~~ 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: docstrings
> Are Django committers willing to accept patches that reformat lines within > 80 characters? > > -- > Nicola Larosa -http://www.tekNico.net/ I was curious - being a 80+ line writer myself - how many lines in trunk were currently longer than 80 chars, so I wrote a short script. Here's what I got (just looking at .py files): Long lines: 2517 All lines : 43930 Proportion: 5.73% That seems like a pretty low proportion of longer lines, but probably more than would be worth retro-fitting (unless you were making other changes). HTML is a bit different (as you might expect): Long lines: 220 All lines : 1539 Proportion: 14.29% (Personally I don't think HTML should be regulated as much - there are several reasons for why you would want longer lines. I just add this for perspective). -rob --~--~-~--~~~---~--~~ 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: ModelChoiceField's clean() uses default manager instead of query set
I'm not sure of the intent, but something to keep in mind is that if you have previously-valid information and wish to save it again, it may become invalid. For example, I have a list of "active" employees for selection in the filtered choice field. If I open up some object and hit "Save" after the employee is no longer active, this would incorrectly raise an error. I would imagine this avoids it. -rob On Aug 6, 10:00 pm, Nick <[EMAIL PROTECTED]> wrote: > The clean() methods in both ModelChoiceField and > ModelMultipleChoiceField use a block similar to the following in order > to validate the selected choice: > > try: > value = self.queryset.model._default_manager.get(pk=value) > except self.queryset.model.DoesNotExist: > raise ValidationError(ugettext(u'Select a valid choice. That > choice is not one of the available choices.')) > > Is there any reason that shouldn't simply be > self.queryset.get(pk=value) ? > > I came across this in a project when I was trying to work out why it > was allowing choices that I had explicitly filtered out of the > queryset - and of course this explains it. Is there a reason that the > default manager should be used instead of just the original queryset? --~--~-~--~~~---~--~~ 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: ModelChoiceField's clean() uses default manager instead of query set
> Hmm, I see what you're saying but (using your example) if the employee > is no longer active, wouldn't that mean the field *should* raise a > validation error? If the choices are meant to be limited to only > employees which are active shouldn't the validation prevent the user > from choosing an option which has been invalidated since the form was > rendered? Not in my case. Among other things, I'm tracking employee's time. So just because they're no longer active doesn't mean the work they did previously is invalid. Although making changes to these records is not common, sometimes some details need to be updated and I don't want to be prevented. I see the choices interface as a convenience / performance tool, but not as a validation tool. > At least that's the reason I came across this in the first place. For > some background: The user needs to choose from a list of objects, and > these objects expire over time. I wanted validation to catch the case > of a selected choice expiring and no longer being valid. I have > created a custom ModelChoiceField which works using the query set > instead of the default manager and that suits my purposes fine, I just > thought I would raise it here to see if this should apply in general > or not. So, this would be a problem if you were using the form for updating records, but reading between the lines it looks like you are using the form only for adding records. However, I'm a little confused now. I thought the problem was only validation, and not the actual data that was added to the choice list. Perhaps its too late for me to be commenting (like usual)... I'll let others speak now :) -rob --~--~-~--~~~---~--~~ 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: ModelChoiceField's clean() uses default manager instead of query set
> That could work. The main point of this thread was to see if there are > use cases for using the default manager for validation instead of the > query set because I couldn't really think of any - but I'm sure there > could well be some. Like the one I explained? :) I think the strongest argument against using adding an extra "validation queryset" argument is that it doesn't give the flexibility of programmatically validating data. A function works much better in this respect. And as for the default behaviour, I've put forth my thoughts on it and I think it is more commonly a problem than the security issue that was suggested (since you probably won't usually construct your forms to allow a user to have any say in their own access). Not incidentally, this is what the "validator_list" has been used for. However I'm not sure if this will remain in place since oldforms is going away... but you should be able to transition it easily if necessary. -rob --~--~-~--~~~---~--~~ 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: ModelChoiceField's clean() uses default manager instead of query set
> Sorry, perhaps I don't quite understand how this is different...
> unless you are rendering the field widget manually and somehow adding
> extra choices that aren't in the query set passed to the
> Model*ChoiceField?
There would be one extra choice - the previously selected, and no
longer valid, related field!
Perhaps I can be clearer with the following example. Please ignore the
details of getting/displaying the form - this is only to show you the
issue with related fields and the choice validation:
class Employee(models.Model):
first_name ...
last_name ...
active ...
class Activity(models.Model):
employee = models.ForeingnKey(Employee,
limit_choices_to={'active__exact':True})
type = models.ChoiceField(...)
duration = models.PositiveSmallIntegerField()
notes = models.TextField()
# again, ignore the details of getting/displaying the form. Just using
the admin will show the potential problem
1) Create new active employee, employee1
2) Create new activity object, activity1 linked to employee1
3) Find employee in intimate relationship with office equipment, fire
employee
4) Edit employee1 so that active=False
5) Edit activity1 (the original employee1 item is still displayed &
selected) to add some notes ("Remember to buy new furniture") & save.
Blam! Can't save because employee is not active, if using the
"active=False" manager. (Currently however, admin would be using the
default manager so it would allow you to save.)
So hopefully you can see why I think it is a good idea to restrict the
choices, for convenience, but not the validation part of the
ModelChoiceField. This doesn't solve all problems - like adding
"activity2" after employee1 is fired - but at least it keeps the
original objects usable.
Now if you really wanted to prevent somebody from cheating the
selection, add the extra validation - but again, this would be easier
as a method (e.g. if superuser, use default manager for validation:
else if editing & the same, return: else use custom manager for
validation).
> I guess my take on it is that if you wanted the user to be able to
> choose from any object you would just pass the default manager as the
> query set instead of passing in a filtered query set in the first
> place.
Because the number of unfiltered items might be unreasonable large, or
at least annoyingly large, in a select field.
> As I said before I'm not too fussed if it's decided that this should
> not apply to the standard Model*ChoiceField classes, but I felt that
> it made sense. I'll shut up now :-)
Well it is a judgement call, not black and white. I've just been in
the situation I've mentioned (except maybe for the office furniture
part!) and I know it would be a major pain to deal with validation
that prevents legitimate use.
-rob
--~--~-~--~~~---~--~~
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: Changeset 5933 is causing breakage
> Ramiro Morales reported a similar thing in #5204. My fault; I'll have a > look at it. It's my fault, too! I'll remember to look through comments next time I write the "too simple" patch. -rob --~--~-~--~~~---~--~~ 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 1.0 features -- the definitive list
On Nov 29, 10:33 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance > * #5361 -- File storage refactoring > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > What am I forgetting? Good choices, Adrian. I talked about this with you guys last sprint (sorry by the way for missing this one) and I think these hit the spot. Various branches may have to scramble a little to get up to date but I think that will give them a better point of reference than "the last time we branched". Also these are clearly backwards incompatible - good to get those out of the way and make the upgrade path easier for those starting with the next major version, and add the less- incompatible changes later. > > And, finally, a bit of a controversial statement, but... > > I think we ought to call the release 2.0. > Well Rails is about to release 2.0... oops, did I say that out loud?! Great stuff! -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
autoescape wrong approach
Hi all, This might seem like beating a dead horse... In the template docs, this phrase is in the notes for escaping: "Generally, template authors don't need to worry about auto-escaping very much." which to me, sounds about right. But clearly template authors DO have to worry about auto-escaping, otherwise they wouldn't ever have a need to fiddle with autoescaping code! Shouldn't this operation occur in the newforms framework, since the distrust comes from user-entered data, and the decisions on what should be trusted and what shouldn't come from the form developer? E.g. unless otherwise specified in the form/field, the "data" argument to BaseForm should be "purified". This would seem safer and simpler to me. (BTW, this doesn't kill me to fix these things in my project, I'm just looking at the feature holistically.) Sorry for bringing this up again, but I didn't find any discussion on this approach in any of the older threads and I'm only now updating my templates. And of course, if it HAS been discussed, please point me to the thread and we won't rehash this. -rob --~--~-~--~~~---~--~~ 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: autoescape wrong approach
> I dunno about you, but I get data from places other than forms. Well then, who makes decisions about trust for that data? --~--~-~--~~~---~--~~ 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: autoescape wrong approach
> * Escaping is solely and entirely a function of presenting data in HTML. > * As such, escaping belongs in the component of Django which handles > presentation of data in HTML. > * As such, the template layer is the correct place for this. All good arguments :) I'm frustrated that the template author doesn't have any detail on whether a variable should be trusted or not, but yeah, what you say is valid. So forms are not a reasonable place for this, and I think the escaping decision would be better closer to the view, but you get into issues there on an easy way to describe which fields are okay and which aren't. Thanks for the speedy responses. I'll keep quiet now :) -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
