Re: Regression problem on admin date format
Am 13.07.2010 um 01:35 schrieb Russell Keith-Magee: >> On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy wrote: >>> Hi, >>> >>> I have confirmed the bug with other non speaking people and I have >>> sent an e-mail to django-i18n group to point out the problem. >>> >>> I have also contacted Marc and he has confirmed that the problem exists. >>> >>> Sorry for the insistence but in my opinion this is a blocker bug. > > On Tue, Jul 13, 2010 at 4:01 AM, Horst Gutmann wrote: >> Did the patch that is attached to this issue work for you? It would >> really be nice to get some feedback on it :-) From what I've heard in >> other posts on this and the django-users list so far it seems to do >> the job. > > Ok - I'll put this on my list of things to look at. I've been fairly > busy at work over the last couple of weeks, and what time I've had > left has been consumed keeping feature discussions going. Once things > settle down, I'll have more time to put into bugs. FYI, I planned to have a look at it this week, too. Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
django 1.2 ModelForm save during post_clean has caused me quite a headache ...
Hi developers, Having just ported to 1.2.1, I'd like to make a comment about a change that was made to the code from 1.1. I understand that you wanted to add a more generic form of model validation into the code base. But I'd just like to let folks know that changing the code such that the ModelForm is saved to an instance during post_clean has caused me, a senior developer that has been working on a django app for 18 months at a large corporation, a lot of problems. Let me give a couple of examples: I have a fairly sophisticated web app that is using django, and a number of features in it depend on the save at exactly the point where my code calls save(). For example, I compare the initial state of an instance prior to the save to the state of the instance after the save, and print a report based on that. I also do some special stuff so that my forms save out only the fields that are changed in the form. My app has some similarities to the admin app (but more custom). Imagine that you have the admin app working in a multi user environment. What if two different users have the same admin page up, and one saves one field in an object, and the other saves another. The admin app will just save the full form for whichever user's save happens last. But my app (which is similar to the admin app in many ways) does some special stuff by modifying exclude dynamically, prior to the save, so that so that the save saves out only the fields that have been modified in the form. Yes, I know from tickets I have posted that modifying exclude dynamically is "not allowed". But saving only the fields that have changed in the form was important to my app, so I went that direction anyway, and it has worked extremely well, providing my users with an intuitive UI where multiple people can modify the same object at once, as longer as they are modifying different fields. It's not clear to me what a better way to do this would have been (on 1.1) But now on 1.2 I have no entry point that will allow me to do that, due to the fact that the save is embedded in _post_clean. I have attempted to make _post_clean() a pass, but of course that doesn't work because the validate_unique() code is now tied in to having the instance saved. Yes, I know that I did make use of the internal API in ways that it was not intended. I understood the risk, and now I will pay the price. During this time I have become intimately familiar with much of the django code base, and I am comfortable modifying it and overridding methods as needed. Hey, you gotta do what you gotta do. But it is certainly disappointing to find that 1.2 is going to require me to override so much. There are of course a variety of tacts I can take - it is by no means a show stopper. At the moment, my tact is to override _post_clean(), making it a pass, and create a clean() method for my base level form (which derives from form.Model form, and which all my other forms derive from) that calls all the old code from 1.1 (ie, validate_unique() and all that it calls). Basically I will try to use the old 1.1 ModelForm validation code, in hopes that I can continue to update to new releases. But it is painful and a shame to be copying all this 1.1 code into my app. I would suggest considering making this new model validation code path optional. IE, give users a way to stay with the old form validation. Or better yet, keep the idea of model validation, but make it more transparent by not actually saving the ModelForm to the instance. It's hard for me to believe that no other developers have encountered this same problem (the problem of having a ModelForm saved at a point in the code where you have no control). But my app may very likely present more dynamic and sophisticated functionality, used in a heavily multiuser environment, than many apps that are developed, so perhaps I am the only one that will have an issue with this. In any case, I hope this nail doesn't come across poorly. I respect the Django developers immensly, but I just want to go on record by lettting you know that you have at least one user that has been caused a lot of pain by this change. I also hope that you will accept me posting this on this "developers" board. I think it is important that you get feedback from someone who is using django heavily, in behalf of a large corporation. I find that when I post tickets, if there is any hint of me doing something out of the ordinary, that my ticket is always closed with the comment that "I shouldn't be doing that".I understand that of course you cannot accommodate everyone, and that you are working as volunteers and I totally respect that. But there is little ability for someone like me - basically one of your power users - to give feedback in any sort of useful forum. So I hope you can spend a few moments thinking about what it feels like to be in my shoes. As django moves forward, I think it might be useful to find a way to partner with cor
Accessible Command Output using self.stdout & self.stderr
I would like to propose that all commands in core.management be modified to enable command output to be directed to self.stdout and self.stderr so that the command output can be captured and made accessible to an application. I use a virtual web hosting environment where no shell access is permitted. I would like to set up an administrative web interface which enables commands to be executed and the command output redisplayed to the user. However, as commands currently send output directly to stdout or stderr, the comand output is not readily accessible (Django 1.2.1). Discussions with Russ McGee on Django Users suggested that some commands, for testing system purposes, are now sending to self.stdout and self.stderr, allowing the target to be redefined and the output to be captured. Only dumpdata and loaddata commands have currently been converted in trunk. I am proposing extending this to all commands in core.management, and suggest that this should be promoted as the norm for custom developed commands also. If agreed, the work required to implement would be: a) convert existing commands b) document the feature c) improve documentation of the existing feature allowing applications to construct their own commands d) improve documentation of how to execute commands programatically (as opposed to in a shell) If there is agreement, I am happy to undertake the above although would appreciate a mentor being available for advice from time to time as this would be my first contribution. Longer term, if an administrative web interface to commands is to be provided, we would need to devise an interface that adapted well into the existing administrative interface. However, I see this as a second stage in the process. First we need the command output to be available. Does the above proposal meet with agreement? What say you all? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Jul 12, 11:43 pm, Russell Keith-Magee
wrote:
>
> > On Jul 12, 12:31 pm, André Eriksson wrote:
> >> Good proposal overall. One thought I have in order to try and combat
> >> the massive parameter list of {% form %} is to optionally add an
> >> ending tag, as well as sub-tags:
>
> >> {% form myform %}
> >> {% using birthday=calendar %}
> >> {% renderer "as_ul" %}
> >> {% autocomplete "name_autocomplete" %}
> >> {% doctype xhtml1 %}
> >> {% endform %}
>
> > I'm +1 on Russell's proposal in general but I'm also -1 on the big
> > parameter list to the proposed {% form %} tag.
>
> Ok - we must have different measures for what constitutes a "long
> parameter list". As I noted in my response to Tim, there's exactly 1
> redundant word in the template tag I've proposed.
>
> The only other way I can think of to shorten the argument list is to
> introduce different tags for rendering a single field, rendering
> top-of-form field errors, and rendering javascript triggers; so:
>
> {% form myform %} -- would render an entire form
>
> but rolling out the full form manually would require:
>
> {% form_errors myform %}
> {% form_field myform.name using autocomplete:"name_ajax" %}
> {% form_field myform.email %}
> {% form_field myform.birthdate using calendar %}
> {% form_triggers %}
>
> To me, this just means a bunch more underscores in templates, and 3
> extra tags to register (along with finding a way to share the form row
> rendering logic between the {% form %} tag and the other tags.
>
Your proposal really needs to cater to two different audiences:
1. People who will use the new {% form myform %} where they just want
all the fields rendered without any fuss, much like {{ form }} now.
2. The tweakers that need to control every aspect of the each field
being rendered.
I probably fall into the latter category. I also have separate logic
for handling form and non-form errors.
Appropriate naming of the new tags is another shed to paint.
> > Having written some
> > complex form field rendering tags for extjs/sencha I can say that
> > without some kind of built-in *args/**kwargs-like parameter handling
> > for template tags, then having more than a handful of parameters gets
> > long and messy quickly.
>
> I'll concede args/kwargs handling in template arguments isn't pretty.
> My counterargument would be that I don't see the use case for lots of
> argument and kwargs to chrome. "Use this calendar", or "show this
> decoration", not "here are 5 different arguments to configure how this
> chrome will operate".
>
> The one use case I can think of for chrome arguments is to provide the
> named URL for AJAX callbacks. However, this may just be a case of me
> not being imaginative enough. If you can provide a use case, I'll
> happily reconsider my position.
I currently pass arguments to my custom tags that allow me to override
the field label, ajax callback, default field value, url for adding
another object (like FK's in admin), and more. Not having args/kwargs
is biting me and i've been too lazy to address it in my own code and I
have to handle cases where args are positional and args 3 and 4
optional but I have to pass an "empty" arg 3 to be able to pass a
valid arg 4.
>
> > Also, it doesn't make your tag that user
> > friendly either when they have to keep referring to the docs to figure
> > out how to use it.
>
> > Andre's idea is interesting and is certainly more readable.
>
> I'm having difficulty reconciling these two positions. My template tag
> is too complex because it requires you to remember the idiom FORM X
> FIELD Y USING Z; but a nested tag structure with 4 different subtags
> is more readable and won't require reference to documentation to
> understand how and when to use each subtag?
The point I am trying to make is that overloading a single tag with
such diverse functionality (that is likely to grow and probably father
more arguments) would be better served by splitting that functionality
into separate tags.
regards
Matthew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
On Jul 13, 9:10 pm, Margie wrote: > Yes, I know from tickets I have posted that modifying exclude > dynamically is "not allowed". Why wouldn't you just modify self.fields? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accessible Command Output using self.stdout & self.stderr
On Tue, Jul 13, 2010 at 2:23 PM, maxweld wrote: > I would like to propose that all commands in core.management be > modified to enable command output to be directed to self.stdout and > self.stderr so that the command output can be captured and made > accessible to an application. > > I use a virtual web hosting environment where no shell access is > permitted. I would like to set up an administrative web interface > which enables commands to be executed and the command output > redisplayed to the user. However, as commands currently send output > directly to stdout or stderr, the comand output is not readily > accessible (Django 1.2.1). > > Discussions with Russ McGee on Django Users suggested that some Magee. I'm not Scottish :-) > commands, for testing system purposes, are now sending to self.stdout > and self.stderr, allowing the target to be redefined and the output to > be captured. Only dumpdata and loaddata commands have currently been > converted in trunk. I am proposing extending this to all commands in > core.management, and suggest that this should be promoted as the norm > for custom developed commands also. > > If agreed, the work required to implement would be: > a) convert existing commands > b) document the feature > c) improve documentation of the existing feature allowing applications > to construct their own commands > d) improve documentation of how to execute commands programatically > (as opposed to in a shell) Seconded, and carried. I've already said I'll accept any patch that implements any (or preferably all) of these points. > If there is agreement, I am happy to undertake the above although > would appreciate a mentor being available for advice from time to time > as this would be my first contribution. I'm happy to give you any feedback you need; if you post to django-dev when you need assistance or feedback, I'll try to respond; if I don't, someone else hopefully will. > Longer term, if an administrative web interface to commands is to be > provided, we would need to devise an interface that adapted well into > the existing administrative interface. However, I see this as a second > stage in the process. First we need the command output to be > available. There may well be a place for these commands to be exposed via a web interface (especially if you're building a shared hosting type environment), but I'm not convinced that this is something that is appropriate to be baked into Django's core. Firstly, it's a bit of an edge case; the biggest use case for this sort of facility is to support a virtual server for which you don't have shell access. I don't have any firm numbers, but I suspect that this is an edge case of Django deployments. Secondly, some management commands aren't really well suited to execute on the same server that is serving them. It may be fine to have one server executing management commands on another, though (especially if you're setting up some sort of push-button hosting environment). Thirdly, some management commands can be time consuming or have the potential for introducing database locks; as such, they aren't well suited to execution in the request/response cycle. This means you should be looking at implementing this using a job queue, and Django is agnostic when it comes to such issues. That said, if such an administrative interface were to be introduced, it would almost certainly be as a contrib application. The usual path for adding new contrib applications is for them to start as a standalone project, and then be integrated when an argument can be made that they are a "defacto standard implementation of a common pattern". If this is something you're enthused about, I heartily encourage you to start it as a standalone project. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
On Tue, Jul 13, 2010 at 5:10 PM, Margie wrote: > Hi developers, > > I would suggest considering making this new model validation code path > optional. IE, give users a way to stay with the old form validation. > Or better yet, keep the idea of model validation, but make it more > transparent by not actually saving the ModelForm to the instance. > It's hard for me to believe that no other developers have encountered > this same problem (the problem of having a ModelForm saved at a point > in the code where you have no control). But my app may very likely > present more dynamic and sophisticated functionality, used in a > heavily multiuser environment, than many apps that are developed, so > perhaps I am the only one that will have an issue with this. Given the remainder of your message, this request is likely to get lost. I'd suggest raising this as a separate thread, wherein you just describe the specific use case and your proposed solution. > In any case, I hope this nail doesn't come across poorly. I respect > the Django developers immensly, but I just want to go on record by > lettting you know that you have at least one user that has been caused > a lot of pain by this change. I don't want to appear rude, but I'm not sure what response you're looking for. I'm not insensitive to the fact that you have code that requires refactoring as a result of the upgrade from 1.1 to 1.2. However, by your own admission, this was a problem of your own making. We have a documented interface. You're not using the documented interface. And as a result, code broke when you upgraded. Python is a language for "consenting adults" -- you have the liberty to modify the internals of anything you can see if you so wish. There's no such thing as a truly 'private' or inaccessible internal. However, just because you *can* tinker with the internals doesn't mean that it's good engineering practice to do so, or that it's our fault when that tinkering ends badly. > I also hope that you will accept me posting this on this "developers" > board. I think it is important that you get feedback from someone who > is using django heavily, in behalf of a large corporation. I find > that when I post tickets, if there is any hint of me doing something > out of the ordinary, that my ticket is always closed with the comment > that "I shouldn't be doing that". I understand that of course you > cannot accommodate everyone, and that you are working as volunteers > and I totally respect that. But there is little ability for someone > like me - basically one of your power users - to give feedback in any > sort of useful forum. So I hope you can spend a few moments thinking > about what it feels like to be in my shoes. Without a history of specific tickets to reference, it's difficult to say what has happened with your tickets in the past. All I can say is that in general terms, the way in which a ticket is phrased can make a big difference to the way it is handled. In this specific case, you claimed there was a backwards incompatibility. That's a pretty big stick to shake -- we take backwards compatibility seriously -- so when it was discovered that you were using a private API, you were shown that it wasn't a backwards incompatibility, and the ticket was closed. By contrast, if your ticket had asked for a specific interface to be formalized or exposed, including the reasons why that interface needed to be formalized, your ticket wouldn't have been shot down immediately. "X doesn't work" is a bug claim that is easy to refute. "It should be possible to do X" is a feature request that at least requires consideration. Of course, a feature request can still be shot down; that's why the very best way to propose a feature is to start with a discussion on Django-developers, so you get the eyes of the entire development community, and you can have an active discussion with that community. Even then, you may find that some features get rejected. Django can't be all things to all people. If you really do have extreme use cases, and your proposal is especially invasive or complex, you may find that we say "no" in the interests of keeping things simple for the 90% of users that don't have extreme use cases. And finally -- sometimes the rejection will be along the lines of "well, it might be a nice idea, but it's a complex issue and we're not intending to look that any time soon". In that case, you will often find that offering to help out (both with your specific itch, and with other related tickets) will grease the wheels immensely. > As django moves forward, I think it might be useful to find a way to > partner with corporate developers such that you get feedback like this > at an earlier point. While I try to keep an eye out for where things > are going with django, this change and it's impact on me just was not > at all clear. Django 1.2 was in development for 9 months. The feature you're describing was committed 5 months before the f
Re: Proposal: Revised form rendering
Your proposal really needs to cater to two different audiences:
1. People who will use the new {% form myform %} where they just want
all the fields rendered without any fuss, much like {{ form }} now.
2. The tweakers that need to control every aspect of the each field
being rendered.
I'd say there's a 3rd subset of folks (Gabriel Hurley and myself
have voiced advocacy for this camp) who would be interested in a
middle-road "mostly the default form, only override the behavior
for fields X & Y". Andre's proposed {% form myform %}...{%
endform %} syntax does this nicely, making it cleaner by removing
the redundancy of referencing the form in each field-modifier and
without the need to manually render each field.
-tkc
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Mon, Jul 12, 2010 at 11:01 PM, Tim Chase
wrote:
> On 07/12/2010 07:03 AM, Russell Keith-Magee wrote:
>>
> Yeah, I'll give you the point that your
> solution looks more elegant for individual field rendering, while one of my
> envisioned use cases was "I want this form exactly as it would normally
> render, only I want to override the widget-choice for a particular field".
> It's the difference between something like
>
> {{ myform|use_widget:"birthdate=calendar"|as_ul }}
>
> and
>
> {{ myform.name }}
> {{ myform.favorite_cheese }}
> {{ myform...8 more fields here }}
> {{ myform.birthdate|calendar_chrome }}
> {{ myform...7 more fields here }}
>
> or perhaps a (forgive the pseudo-code template) slightly less verbose
> version:
>
> {% for field in form.fields %}
>
> {% if field.name == "birthdate" %}
> {{ field|calendar_chrome }}
> {% else %}
> {{ field }}
> {% endif %}
>
> {% endfor %}
Ok - now I see where you're driving at. I wasn't trying to hit this use case.
One of the historical traps that form rendering discussions have
fallen into is the idea that somehow we can come up with the One True
Rendering Implementation; if we just add enough options and flags, we
will be able to programatically define all the fieldsets, field
alignments, and individual per-field layout options you could ever
want.
The core team has generally rejected these proposals, for the same
reason we have rejected ORM extensions that expose edge cases of SQL.
We have a language for describing form layouts -- it's called HTML.
Trying to come up with programatic abstractions of HTML just leads to
leaky abstractions.
I know that's not what you're proposing here, but I'm wary of getting
into territory where it looks like that might be what we're willing to
support. By tackling the form layout problem as a set of rules for
rendering individual fields, it leaves no doubt that you're *supposed*
to manually layout forms if you have rendering requirements that step
outside the simplest possible case.
I'd also like to think that it would be easy enough to write a chrome
package in a way that doesn't require "if field.name == birthdate"; I
would have thought that chrome could generally be applied on a
per-field-type, rather than per-field-name basis (ie. apply calendar
to all dates, rather than having to specifically name the date
fields). However, absent of an actual implementation, it's difficult
for me to actually assert this.
>> but the final syntax is no more than:
>>
>> {% form A field B using C D ... %}
>
> With your clarification that this is a *field* rendering, not a *form*
> rendering, I'm more okay with this now. Waffling between a -0 and a +0, but
> easily swayed either direction depending on readability vs. power (yay,
> whitespace and args/kwargs). I still begrudge the "form" keyword as
> misleading (and possibly redundant) as you're talking about fields. I'd
> prefer something like
>
> {% field myform.myfield using ... %}
> {% field some_formless_field using ... ? ... %}
> {% modify_field myform.myfield using ... %}
>
> or some such variant that emphasizes the field-nature instead of the
> form-nature. (I don't know if formless fields would ever reasonably show up
> in a template, so take that psychopathical/hypothetical example with a grain
> of salt)
I toyed with using multiple tags; I ended up proposing a single tag to
keep the internal implementation simple. Given that {% field %} needs
to use the per-row logic defined as part of {% form %}, using a single
tag with a qualifying argument was the easiest way I could see to
avoid duplicating logic. However, there are some other ways that this
could be achieved.
> Thanks for your detailed response and thoughtful arguments.
Likewise.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Mon, Jul 12, 2010 at 11:29 PM, André Eriksson wrote:
> It appears my reply got eaten so I'm trying again.
>
> On Jul 12, 3:43 pm, Russell Keith-Magee
> wrote:
>> I'm having difficulty reconciling these two positions. My template tag
>> is too complex because it requires you to remember the idiom FORM X
>> FIELD Y USING Z; but a nested tag structure with 4 different subtags
>> is more readable and won't require reference to documentation to
>> understand how and when to use each subtag?
>
> My biggest issue with using {% form myform field A %} to render a
> single field is the non-DRY-ness of it all, especially if you have a
> semi-large form. The issue being that if one field has its chrome
> changed, all the other fields must be hand-defined as well. Example:
>
> {% form myform field A using X Y %}
> {% form myform field B %}
> {% form myform field C %}
> {% form myform field D %}
> {% form myform field E %}
> ...
>
> My proposition was to let the {% form myform %}{% endform %} block
> tag render the whole form if desired, akin to how {{ myform }} works
> today. In this scenario, {% using %} would override the chrome of the
> field without affecting its order in the form. As such, the above
> becomes:
>
> {% form myform %}
> {% using A = X Y %} {# Or some other syntax #}
> {% endform %}
>
> Perhaps this wasn't clear enough from my original proposition.
It wasn't in the direction I was originally thinking, so there was
some confusion on my part. I have a better understanding of what you
(and Tim) proposing now, and I've responded with some of my reasoning
in my response to Tim.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
Let's take the admin changelist as an example again. I have a changelist just like this. Let me give a sequence of steps: 1. User1 and User2 both have the changelist displayed on their screen, and both are displaying objects A and B. Let's say the objects have a 'name' field, and objectA's name field is set to 'A', and objectB's name field is set to B 2. User1 sets objectA's 'name' field to 'foo', then saves 3. User2 is still looking at his view of the changelis and still sees objectA's name field with the value 'A' (ie, User2 has not refreshed) User2 now sets objectB's name field to 'bar', and saves. In this scenario, when User2's save happens (#3), I need to make sure that the save does not overwrite objectA's name field with 'A'. For each form in the changelist, I need to identify what has changed in the form, and then save only those fields. I did this through a couple mechanisms: 1. I use hidden_initial and always send the initial data with the form 2. When processing a POST, for each field in the form, I compare hidden initial to the data sent by the user (I simply use changed_data(), as this works with hidden_initial). If the data for a field has changed, then I want to save that field. If it hasn't, I don't. On a form by form basis, I set exclude, just prior to calling save, to cause it to save the right fields. I think to do this only using self.fields, I would have to create two forms for each item in the changelist. I would first have to create a form that has all of the fields, then identify which fields have changed, then based on that, create a new form containing just those fields. Or I could of course just not use ModelForms, and use a non- model Form and do all the save logic myself. But setting exclude prior to the save really worked beautifully. I would think the changelist could benefit from this paradigm as well. Margie On Jul 13, 5:41 am, SmileyChris wrote: > On Jul 13, 9:10 pm, Margie wrote: > > > Yes, I know from tickets I have posted that modifying exclude > > dynamically is "not allowed". > > Why wouldn't you just modify self.fields? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Tue, Jul 13, 2010 at 12:28 AM, Preston Timmons
wrote:
> Hey Russ,
>
> I think this is a great proposal so far!
>
> Is there a way with the proposed solution for the template designer to
> add custom attributes to a form field? If so, do you envision that
> happening in the chrome layer?
Under my proposal as I presented it -- yes, it's a chrome issue.
Chrome is essentially a set of operations that can be performed on the
raw widget output; adding attributes, classes, wrapping the widget
HTML in other HTML, or registering the need for trigger Javascript.
As a helper mechanism, we could ship a generic "attribute" chrome that
allows you to set or override a specific attribute:
{% form myform field name using attr:"autocorrect=off" %}
Adding classes could also be handled as chrome:
{% form myform field name using class="colorful large" %}
Since chrome can be stacked, you could have multiple attr, class, or
any other chrome.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Tue, Jul 13, 2010 at 3:03 AM, Gabriel Hurley wrote:
> Hi all,
>
> I'm certainly excited to see improvements in the form rendering arena,
> so thanks Russ for putting in the work here!
>
> I work with Django plenty as a programmer, but in truth I work more as
> a designer. And as a designer, I've spent more than my share of time
> wrangling Django's existing templating mechanisms into forms which
> accomplish the requisite goals. As such, I'd like to chime in on a few
> cases that certainly matter to me:
>
> 1. Ability to add attributes to individual fields.
> And I don't think writing custom
> chrome is the place to add these types of attributes. They're
> functional, not presentational.
As noted in my reply to Preston, this should easily possibly using
chrome; I'm not sure I see why you disagree. The new options may be
funcitonal, but from my reading of the HTML5 spec, they're functional
in terms of UX, not in terms of data modification. The widget and
field are used to process and parse the content of any value that is
POSTed by a form; anything that the user sees about a form is a
presentational issue, AFAICT.
> 2. Ability to alter individual fields without writing out the entire
> form.
I missed the focus of Tim et al's proposals on this front; I can now
see what he's driving at. To that end, I can see the appeal of a {%
form %} syntax that allows for overriding individual field settings.
> 3. Syntax and Readability.
>
> There's been a lot of discussion on template tag(s) vs. filters, and
> while wearing my designer hat I'd say that calling a "form" tag to
> render individual fields doesn't make sense. Adding a {% field %} tag
> or something of the sort sits better with me.
Sure; I've admitted elsewhere in this thread that my use of a single
tag was mostly driven by a desire to keep the implementation simple.
This was especially important keeping in mind that my original intent
was that extension would be largely in code; this becomes less of an
issue if templates become a larger part of the common usage of this
new form rendering approach.
> 4. Layout renderers being loaded implicitly by form libraries.
>
> I'm a HUGE -1 on this. The choice of "as_ul", "as_p", etc. needs to be
> as explicit as possible, and the idea that you could load multiple tag
> libraries and accidentally override your form rendering sounds like a
> nightmare. So, whether these become filters, or arguments to the {%
> form %} tag, I really can't support them being implicit in the form
> tag that gets loaded. No magic here, please!
I think I understand the nature of your concern, but I'm not sure if I
agree with calling this magic. You import a library that exercises the
defaults you want to use. Library loads only survive for the duration
of a single template, so there isn't any risk of a load in one
template file accidentally changing behavior elsewhere.
That said, the block-based {% form %} rendering proposal potentially
gets around this by opening the possibility of making the layout
selection a subtag that is explicitly specified in the context of a
specific {% form %} instance.
Thanks for the feedback, Gabriel.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
You are right, I should have tried out the trunk much earlier. And I agree that Python is a language for consenting adults (ad pretty much everything you said) so I won't hash it out. I went outside the interface, and now I have to deal with it. I think this came about because I really never communicated the "field based save" paradigm (discussed in my previous response) that I am trying to implement in an effective way. I did mention it in bug posts, but the developer response always focused on the details of the "bug" I was reporting, and never on the paradigm. Perhaps i didn't describe the paradigm well enough. For example, take a look at http://code.djangoproject.com/ticket/12337, which relates to me trying to change exclude dynamically. In that bug I did try to describe the field-based save paradigm I was trying to implement, but I didn't get anywhere. Perhaps I was to focused on the details of the "bug", and instead I should create a more general ticket that discusses the paradigm I am trying to implement? It just hasn't seemed like I've gotten any sort of acknowledgement that this paradigm is useful. I don't know if that's because I haven't explained it well, or I haven't focused on it enough, or it's just too complex for folks to think about, or if everyone is just busy. No doubt some combination. Would you suggest I create a bug ticket that describes this "field based save" paradigm and asks if there is an interface we could develop to formalize it? I don't know exactly what that interface would be yet, so I feel like it would be somewhat premature for me to suggest the actual interface without some acceptance that the paradigm is a good one, but if folks think the paradigm is a good one, I would be happy to work on the interface. Thanks for your comments. Margie On Jul 13, 6:46 am, Russell Keith-Magee wrote: > On Tue, Jul 13, 2010 at 5:10 PM, Margie wrote: > > Hi developers, > > > I would suggest considering making this new model validation code path > > optional. IE, give users a way to stay with the old form validation. > > Or better yet, keep the idea of model validation, but make it more > > transparent by not actually saving the ModelForm to the instance. > > It's hard for me to believe that no other developers have encountered > > this same problem (the problem of having a ModelForm saved at a point > > in the code where you have no control). But my app may very likely > > present more dynamic and sophisticated functionality, used in a > > heavily multiuser environment, than many apps that are developed, so > > perhaps I am the only one that will have an issue with this. > > Given the remainder of your message, this request is likely to get > lost. I'd suggest raising this as a separate thread, wherein you just > describe the specific use case and your proposed solution. > > > In any case, I hope this nail doesn't come across poorly. I respect > > the Django developers immensly, but I just want to go on record by > > lettting you know that you have at least one user that has been caused > > a lot of pain by this change. > > I don't want to appear rude, but I'm not sure what response you're looking > for. > > I'm not insensitive to the fact that you have code that requires > refactoring as a result of the upgrade from 1.1 to 1.2. However, by > your own admission, this was a problem of your own making. We have a > documented interface. You're not using the documented interface. And > as a result, code broke when you upgraded. > > Python is a language for "consenting adults" -- you have the liberty > to modify the internals of anything you can see if you so wish. > There's no such thing as a truly 'private' or inaccessible internal. > However, just because you *can* tinker with the internals doesn't mean > that it's good engineering practice to do so, or that it's our fault > when that tinkering ends badly. > > > I also hope that you will accept me posting this on this "developers" > > board. I think it is important that you get feedback from someone who > > is using django heavily, in behalf of a large corporation. I find > > that when I post tickets, if there is any hint of me doing something > > out of the ordinary, that my ticket is always closed with the comment > > that "I shouldn't be doing that". I understand that of course you > > cannot accommodate everyone, and that you are working as volunteers > > and I totally respect that. But there is little ability for someone > > like me - basically one of your power users - to give feedback in any > > sort of useful forum. So I hope you can spend a few moments thinking > > about what it feels like to be in my shoes. > > Without a history of specific tickets to reference, it's difficult to > say what has happened with your tickets in the past. All I can say is > that in general terms, the way in which a ticket is phrased can make a > big difference to the way it is handled. > > In this specific case, you clai
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
On Tue, 13 Jul 2010 02:10:03 -0700 (PDT) Margie wrote: > It's hard for me to believe that no other developers have encountered > this same problem (the problem of having a ModelForm saved at a point > in the code where you have no control). I did face the same problem in a more straightforward application, I've a model with multiple submits, only one of them should actually modify the model instance. now the moment is_clean() is executed the instance gets modified. wasn't fun to track the related bugs. I read about this backward incompatible change in http://docs.djangoproject.com/en/dev/releases/1.2/#modelform-is-valid-and-modelform-errors but did not understand what it meant except in hindsight. I'm actually still not sure what the advice to pass a copy to the ModelForm constructor means (I suppose it could mean override __init__ and use copy.copy). cheers, Alaa -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Advanced Permissions
Hello. My name is Nate. Myself and my friend Marco would like to upgrade django permissions. We would like to brainstorm here first to make sure that we design something that fits with django. If there are any other discussions about upgrading django permissions, kindly point me to them. We have already some of the permissions threads on django-dev, but we thought that it would be best to make a new thread for our proposal. We are aware of the fact that django 1.2 added some hooks for row- level permissions, but this proposal covers an even broader scope. # The Proposal # In a nutshell, we would like to add a PermissionManager to django. It will be similar in concept to the 'objects' queryset Manager that already exists on models. Each model will have a default PermissionManager attached. People can override this PermissionManager with their own PermissionManager to change the permissions for a particular model. The default PermissionManager works like the current permissions system: it checks all of the Backends to see if the user has the given permission. (This, in turn, checks the records of auth.Permission by default.) The simplest use case of the PermissionManager is overriding it to add new permissions, equivalent to setting the Meta.permissions attribute. For example: class Poll(models.Model): permissions = PermissionManagerWith(vote='Can Vote') ... Note that PermissionManagerWith would be a factory function to create a new PermissionManager class with a vote permission. More on this later. Unlike the current system, PermissionManagers make a distinction between two types of permissions: object-level (row-level) and model- level permissions. Model-level permissions are similar to the current permissions that django has, while object-level permissions add more fine-grained control. ## Model Level Permissions ## Each PermissionManager has an 'allows_PERM' classmethod for each model- level permission. For example, a PermissionManager with the model- level permissions 'add', 'remove', and 'edit' will have the functions 'allows_add', 'allows_remove', and 'allows_edit'. These functions take a User object as a parameter and return a boolean as to whether or not the user has the given permission. So, for instance, a user could do the following: if not Poll.permissions.allows_vote(user): raise PermissionError By default, this will check all of the authentication Backends to see if the user has the given permission. Users could, of course, extend PermissionManager and override this behavior to use other methods of checking the permissions. Note, however, that these functions are defined on a Class level. Users overriding these functions can not do any computation concerning a model instance, only a model class. This does not allow people to do things like restrict edits to only models that the editor created. For that, you need object-level permissions. ## Object Level Permissions ## Each PermissionManager has a 'PERM_list' classmethod for each object- level permission. For example, a PermissionManager with the object- level permissions of 'remove' and 'edit' will have the functions 'remove_list' and 'edit_list'. These functions take a User object as a parameter and returns a queryset of all the objects for which the user has the specified permissions. So, for instance, you might see something like this in contrib.admin: queryset = Book.permissions.edit_list(user) By default, this is either all of the objects or none of the objects, depending upon the authentication backends. However, this is what is overridden to get more fine-grained permission control. For example, consider the following: class BookPermissionManager(PermissionManager): def edit_list(self, user): return super(BookPermissionManager, self).edit_list(user).filter(author=user) class Book(models.Model): author = models.ForeignKey(User) permissions = BookPermissionManager ... This is an example of using PermissionManagers to only allow users to edit books that they themselves authored. Note that this proposed permissions system does not require that we add any tracking or meta- data to the database. If users would like to base permissions on the meta-data of objects, then they need to store such meta-data themselves. This permissions system will by default use only the existing auth.Permission system for permissions. For symmetry and ease of use, each PermissionManager instance has an 'allows_PERM' method for each object-level permission. The default implementation of allows_PERM is this: def allows_PERM(user): return self.model in self.PERM_list(user) and it is strongly recommended that allows_PERM not be overridden for object-level permissions, because changes in allows_PERM will not be reflected in PERM_list. ### Adding Permissions ### The most common overriding of PermissionManagers will be adding new object-level or model-level permissions. This use case is currently the onl
Re: Proposal: Revised form rendering
On Tue, Jul 13, 2010 at 3:24 AM, Carl Meyer wrote:
> Hi Russ,
>
> First of all, thanks very much for this proposal! Form rendering has
> been a major pain point for us (thus the existence of
> django-form-utils), and improving it is tops on my 1.3 wishlist. I
> will also be at DjangoCon and eager to sprint in this area.
Excellent. Sounds like we might have a posse of form wranglers forming.
> I'll first outline in brief what I think a fully template-oriented
> approach might look like, address some possible concerns with it, and
> follow that with some specific comments on your proposal.
>
> A fully template-based approach to form rendering
> =
An interesting counterproposal Carl; thanks for the input.
> Possible objections
> ---
>
> - Russ mentions the "complexity" of "getting all the template paths
> lined up." I'm not sure what the issue is here; Django template
> overrides use a simple path-based scheme, and it's a proven system
> that works. Designers use it successfully all the time. I think
> introducing new complexity in the form of new Python abstractions is
> more likely to be a real problem.
To explain my concerns, I perhaps need to explain my motivation better.
When I introduced the Media framework 3 years ago, I had something
very specific in mind: I wanted to start a marketplace for reusable
widgets.
I have exactly 0 mad skillz as a front end guy, but I know that rich,
pretty ajax widgets et al are necessary for a good user experience. My
goal, as a backend guy with limited frontend skills, was to find a way
to get the people who *did* have frontend skills to be able to package
their widgets in such a way that I could reuse them.
Before the design community starts to think that I'm trying to
minimize the importance of what they do -- I know that there's a lot
more to the design process than this. I'm just looking at this from a
prototyping perspective -- I should be able to get a decent calendar
or AJAX autocomplete onto a page without much more effort than it
takes to put a simple text field on the page. The legacy of "How does
Django do AJAX" questions on django-users is the more public face of
this desire.
Now, the Media framework has been largely a flop in this regard
(although we may be able to use bits of it in a support role in this
new form work). However, my desire for a widget library is unquenched
:-)
My concern about doing this entirely in templates is that it makes the
process of sharing a widget library a little more difficult. If it's
just code, then it just needs to be in the PYTHONPATH. If there are
templates too, then the templates need to be somewhere that they can
be accessed.
There's also more to a widget in this context than just the template
-- for example, there's nominating the javascript triggers that the
widget requires.
I'm not saying that these problems can't be overcome -- just that it's
a complexity that I want to make sure is covered.
> - Concerns about filter syntax. The first two concerns Russ raised are
> only issues if many filters have to be strung together, which this
> proposal does not require. The third objection is predicated on the
> necessity of doing tricks with the context to load widget JS; again,
> a template-based solution doesn't need this.
The filter syntax doesn't hit the 'render the form completely standard
except for this one change on this one field' use case. However,
there's nothing about the 'template' aspects of your proposal that
need to be bound to filters; they could be equally accomodated in a
template tag.
> - "Too much work to override all these widget templates just to switch
> doctypes!" Again, I think the complexity of dedicated Python
> machinery is likely to be worse. Django's philosophy (and James
> Bennett's philosophy of reusable app templates, referenced above)
> assume that templates should be per-project: why should forms or
> widgets be different? Packaging up a reusable app with a set of
> generic "HTML5" or "XHTML1" widget templates is almost certainly
> simpler (and less bug prone) than writing the equivalent Python code
> for the customized {% form %} tag renderer.
My manifestation of this problem is slightly different -- it's the
issue of how to ship a widget library that can be used anywhere. I
suppose one argument here is that you just need to advertise your
chrome with doctype support notes.
Alternatively, since this is a template language, you could always
introduce an {% if %} block and render conditionally on doctype...
> - I'm skeptical that the "chrome" abstraction buys very much in
> exchange for the overhead of the new concept and the syntactical and
> registration problems. As mentioned above, in practice I don't think
> layering different chromes on top of each other will work very
> often; they'll frequently have to be manually integrated into a new
> unified chrome anyway.
This depends a little
Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...
I think that what that http://docs.djangoproject.com/en/dev/releases/1.2/#modelform-is-valid... is saying is that if you don't want your instance to get modified by is_valid(), then when you initially create your ModelForm, you should pass in a copy of your instance. Something like this: instanceCopy = deepcopy(instance) form = MyFormClass(instance=instanceCopy, data=data) That way when you call form.is_valid(), it will write to instanceCopy, not instance. However, I don't think just doing a deepcopy() will work if your instance has m2m fields. You end up copying a pointer to the m2m field, and both instanceCopy and instance will point to the same m2m field, and if that m2m field then gets modified by the save associated with is_valid(), your instanceCopy m2m field will look modified as well. I would be curious to know what the is the appropriate tact to take on this. In my case, I want to compare the saved instance to the pre-clean instance. Previously I did this in my save() method, but now I guess I have to make a copy of the instance prior to creating my form. This is shame because it means I have to copy the instance even in the case where I am not ultimately going to save to the database. For example, in the case where the user submitted form has an error. I now have no entry point that allows me to identify there is an error, and then make the decision about whether to make the instance copy. In general, I find it very problematic that I now have no ability to make a decision or take any action after form validation, but prior to instance save. It seems like all sorts of workarounds are needed in one's code if you have requirements that previously (in 1.1) could be fulfilled by taking some action based on form validation, but prior to instance save. However, as Russell has noted, I am sadly very late in making this observation. Margie On Jul 13, 8:28 am, Alaa Abd El Fattah wrote: > On Tue, 13 Jul 2010 02:10:03 -0700 (PDT) > > Margie wrote: > > It's hard for me to believe that no other developers have encountered > > this same problem (the problem of having a ModelForm saved at a point > > in the code where you have no control). > > I did face the same problem in a more straightforward application, I've > a model with multiple submits, only one of them should actually modify > the model instance. now the moment is_clean() is executed the instance > gets modified. wasn't fun to track the related bugs. > > I read about this backward incompatible change > inhttp://docs.djangoproject.com/en/dev/releases/1.2/#modelform-is-valid... > but did not understand what it meant except in hindsight. I'm > actually still not sure what the advice to pass a copy to the ModelForm > constructor means (I suppose it could mean override __init__ and > use copy.copy). > > cheers, > Alaa -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Hi Russ,
On Jul 13, 12:11 pm, Russell Keith-Magee
wrote:
> I have exactly 0 mad skillz as a front end guy, but I know that rich,
> pretty ajax widgets et al are necessary for a good user experience. My
> goal, as a backend guy with limited frontend skills, was to find a way
> to get the people who *did* have frontend skills to be able to package
> their widgets in such a way that I could reuse them.
Indeed, I share that goal.
> Now, the Media framework has been largely a flop in this regard
> (although we may be able to use bits of it in a support role in this
> new form work). However, my desire for a widget library is unquenched
> :-)
>From my perspective as a programmer, I think the Media framework is
brilliant. It just has one gigantic Achilles heel: it requires
touching Python code.
Honestly, I think if we're serious about wanting a vibrant ecosystem
of Django-enabled frontend widgets, design goal #1 should be that
creating a widget requires touching zero Python code. And I think
that's possible to achieve.
> My concern about doing this entirely in templates is that it makes the
> process of sharing a widget library a little more difficult. If it's
> just code, then it just needs to be in the PYTHONPATH. If there are
> templates too, then the templates need to be somewhere that they can
> be accessed.
So I think this is very much a programmer's perspective, almost
humorously so :-) "Just code" may seem easy to you, but from the
perspective of at least one experienced Django-template designer I've
talked to, being able to do it entirely in templates makes the idea of
sharing a widget library conceivable, as opposed to almost impossibly
intimidating if its "just code."
The app_directories template loader is installed by default. Getting
templates "somewhere they can be accessed" means creating a directory
on the PYTHONPATH with an empty models.py, an empty __init__.py, and a
"templates/" subdirectory, then putting that in INSTALLED_APPS. That's
it. How is that harder than following exactly the same steps for an
app that includes Python code? From the perspective of a non-
programmer, it's much easier.
> There's also more to a widget in this context than just the template
> -- for example, there's nominating the javascript triggers that the
> widget requires.
Yep, I had a lengthy conversation with Idan in IRC yesterday about how
to approach this. I touched on it in my proposal above briefly (it can
still just be handled with templates), but didn't discuss details like
the fact that a given widget's "JS/media" template should only be
included once on a page, regardless of how many times that widget was
used on the page, even in multiple forms. Which means that the
"render_form_js" filter probably actually needs to be a tag, so it can
accept an arbitrary number of form objects and render the widget JS
once for every widget in every form.
> I'm not saying that these problems can't be overcome -- just that it's
> a complexity that I want to make sure is covered.
Indeed. I think they can be overcome, but I fully agree that the
template-based proposal needs more fleshing-out to make sure it covers
all these use cases adequately.
> The filter syntax doesn't hit the 'render the form completely standard
> except for this one change on this one field' use case. However,
> there's nothing about the 'template' aspects of your proposal that
> need to be bound to filters; they could be equally accomodated in a
> template tag.
I agree that tag vs filter is an orthogonal question, and I'm not
opposed to converting them to tags. I agree that it may be necessary
in order to add an extra optional argument or two to handle some use
cases.
The default-except-for-this-one-field use case is actually quite
doable under the proposal as written; you'd just create a derivative
form-rendering template that inherits your default one, and just
override a small block of it to add a bit of conditional logic to
render a certain field differently, otherwise deferring to
block.super. That's DRY and reasonably easy, but I if render_form were
converted to a tag it might be possible to add some optional arguments
to it to make it even easier.
The other improvement I would probably want to make to the API as I
first proposed it would be a way to point a given form-render or field-
render at a given directory of widget-templates, with the individual
template still picked out by widget-name.
> My manifestation of this problem is slightly different -- it's the
> issue of how to ship a widget library that can be used anywhere. I
> suppose one argument here is that you just need to advertise your
> chrome with doctype support notes.
>
> Alternatively, since this is a template language, you could always
> introduce an {% if %} block and render conditionally on doctype...
Exactly. I can imagine a number of different ways a reusable widget
library might approach this problem: simply advertise support for a
certain doctype (don't di
Re: Proposal: Revised form rendering
Thanks for the thoughtful reply, Russ! Just a couple quick points:
> As noted in my reply to Preston, this should easily possibly using
> chrome; I'm not sure I see why you disagree. The new options may be
> funcitonal, but from my reading of the HTML5 spec, they're functional
> in terms of UX, not in terms of data modification. The widget and
> field are used to process and parse the content of any value that is
> POSTed by a form; anything that the user sees about a form is a
> presentational issue, AFAICT.
Having now read that reply, I see what you mean about the chrome. I
hadn't understood chrome as being something that could be "layered".
It sounded more like your idea was "here is a complete calendar UI
solution" and that to add new attributes you'd essentially have to
subclass/rewrite the whole piece of chrome. If they're "stackable",
I'm all for it.
> > So, whether these become filters, or arguments to the {%
> > form %} tag, I really can't support them being implicit in the form
> > tag that gets loaded. No magic here, please!
>
> I think I understand the nature of your concern, but I'm not sure if I
> agree with calling this magic. You import a library that exercises the
> defaults you want to use. Library loads only survive for the duration
> of a single template, so there isn't any risk of a load in one
> template file accidentally changing behavior elsewhere.
The case where it becomes "magic" is if tag library authors start
including these renderers with bundles of other tags... so you go to
load up your favorite handy tag library, and you forget that it also
comes with a custom renderer, and suddenly you've got a mess on your
hands because it replaced your explicitly-loaded renderer. Admittedly
it's not the most common case, but it still concerns me.
> That said, the block-based {% form %} rendering proposal potentially
> gets around this by opening the possibility of making the layout
> selection a subtag that is explicitly specified in the context of a
> specific {% form %} instance.
That certainly seems reasonable to me.
> Thanks for the feedback, Gabriel.
Thank you!
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote: > What exactly is your use case for something that designers want to > customize in the raw widget that widget.render() doesn't expose? That reminds me of one thing I'd very much like to see in any refactoring of form/widget handling. I'd like to be able to get at the "rendered" data (I say rendered, what I suppose I really mean is "transformed" either due to rendering needs or conversion from a graphical representation in the widget to something that could be resubmitted), without any of the surrounding chrome. There are various cases in which this can be useful, the most obvious of which is to tell whether the data in the form has been edited before submission. It's currently not possible to work this out from the "before" and "after" data, as you don't know how any particular field's data might have been munged by the widget (e.g. how is empty data rendered, any forcing to unicode, Python boolean to textual representation, date format transformation etc.). This would make solving problems like those in #11303 simple. As another example, changeset 10757 is heading down this path to fix #10288 in adding the _format_value method. I'd suggest that this be generalised and applied to all widgets (and the _format_value or whatever you want to call it to lose the "_" and be documented as part of the widget API). In one project here, I've had to write "duplicate" versions of all widgets to add a "disable" method and enable them to disable themselves in the UI while still submitting data (actually I'd like the standard widgets to support this too, but... ;-) ); while doing so I took the opportunity to refactor slightly more and ensure that all munging of data took place in one method which could then be used for the purpose described above - which worked just fine. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Hi Russ and Carl,
On Jul 14, 5:55 am, Carl Meyer wrote:
> Hi Russ,
>
> On Jul 13, 12:11 pm, Russell Keith-Magee
> wrote:
>
> > My manifestation of this problem is slightly different -- it's the
> > issue of how to ship a widget library that can be used anywhere. I
> > suppose one argument here is that you just need to advertise your
> > chrome with doctype support notes.
>
> > Alternatively, since this is a template language, you could always
> > introduce an {% if %} block and render conditionally on doctype...
>
> Exactly. I can imagine a number of different ways a reusable widget
> library might approach this problem: simply advertise support for a
> certain doctype (don't discount the value of supporting this low-
> barrier-to-entry option, even if it isn't ideally reusable), or use
> template conditionals, or provide separate widget templates for
> separate doctypes... I find it preferable to make the full power of
> the template language available, and then let template authors use the
> tools they know to iterate towards best practices in this area, rather
> than hardcoding into Django particular ideas of which doctypes are
> relevant and what changes have to be made in templates to support
> them. It's not just a matter of closing slashes, also which attributes
> are valid (of which there may be more added later that we don't even
> know about now)... I think hardcoding current assumptions about
> doctypes is just asking for maintenance headaches. I'd much rather
> leave that concern where it belongs, fully in the hands of template
> authors.
I wouldn't like to see widget libraries being packaged up with
templates including conditional templates based on doctype. This seems
messy, not friendly to override in your own templates, and effectively
combining what should be multiple separate templates into one.
Wouldn't a mechanism that allows the path from which templates are
loaded to be changed benefit both widget libarary authors and the
designers who are implementing those widget libraries? A widget
library author would include and advertise templates for each doctype
they support, e.g. "html4/mywidgetlibrary/forms/datetime.html" and
"xhtml1/mywidgetlibrary/forms/datetime.html", then the designer would
use:
{% templatedirs "html4/mywidgetlibrary" %}
{{ myform }}
{% endtemplatedirs %}
or:
{{ form.myregulartextfield %}
...
{% templatedirs "html4/mywidgetlibrary" %}
{{ myform.mydatetimefield }}
{% endtemplatedirs %}
to load the appropriate template from the widget library templates.
This gives a lot of flexibility and allows widget library authors to
support multiple doctypes or flavours (not just specific to doctypes),
and designers to pick and choose (or even override at the project
level) the widget templates according to their doctype or preferred
flavour, without Django needing any specific machinery for doctypes or
designers needing to edit any Python code.
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Hi Tai,
On Jul 13, 8:42 pm, Tai Lee wrote:
> I wouldn't like to see widget libraries being packaged up with
> templates including conditional templates based on doctype. This seems
> messy, not friendly to override in your own templates, and effectively
> combining what should be multiple separate templates into one.
I agree with you that separate template trees is much better than
conditionals. Also, if using conditionals, where does the value come
from that the conditional switches on? Part of my idea is that there
should be no need for some magic "use this doctype" value to be passed
around.
> Wouldn't a mechanism that allows the path from which templates are
> loaded to be changed benefit both widget libarary authors and the
> designers who are implementing those widget libraries? A widget
> library author would include and advertise templates for each doctype
> they support, e.g. "html4/mywidgetlibrary/forms/datetime.html" and
> "xhtml1/mywidgetlibrary/forms/datetime.html", then the designer would
> use:
Your {% templatedirs %} tag is an intriguing idea in its own right,
and certainly could intersect with template-based form rendering, but
I'd prefer to keep the two proposals orthogonal.
> This gives a lot of flexibility and allows widget library authors to
> support multiple doctypes or flavours (not just specific to doctypes),
> and designers to pick and choose (or even override at the project
> level) the widget templates according to their doctype or preferred
> flavour, without Django needing any specific machinery for doctypes or
> designers needing to edit any Python code.
I totally agree with this. I think very similar results can be
achieved in the form-rendering system just with an optional parameter
to a "form/render_form" tag that specifies a "base path" for finding
template widgets for this form render, as I mentioned above. I think
it's better to keep the form-rendering proposal specific to forms, and
evaluate {% templatedirs %} separately as a feature proposal on its
own merits.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Carl's proposal is exactly the kind of thing I was suggesting in my first response to this thread (only better thought out and stated more eloquently than I could have). Count me as a big +1 to it! Thanks, Eric Florenzano -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Revised form rendering
Hi Carl,
On Jul 14, 11:44 am, Carl Meyer wrote:
>
> I totally agree with this. I think very similar results can be
> achieved in the form-rendering system just with an optional parameter
> to a "form/render_form" tag that specifies a "base path" for finding
> template widgets for this form render, as I mentioned above. I think
> it's better to keep the form-rendering proposal specific to forms, and
> evaluate {% templatedirs %} separately as a feature proposal on its
> own merits.
To me this sounds like basically the same thing, but limited to the {%
form %} and possibly {% field %} tags as a positional argument,
instead of being a generic tag that can be used for multiple forms and
form fields, as well as other (non-form) purposes.
I don't want to hijack this thread and take the focus away from
enhanced form rendering, but if such a feature is going to be tied to
forms specifically I'd like to see that it can be applied to multiple
{% form %} and {% field %} tags, without having to define a new "base
path" for each individual form or field that needs to be customised,
which is what led me to the use of a block tag instead of positional
arguments, and it just so happens that it could be useful outside of
form rendering so I tried to come up with a generic name :)
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Django Unit Test on urls / views
Hello,
I am want to write django 1.1 test case on fedora 12 x86_64.
To test the url I want to session to be persistent so that the next
test can use the same context. I can use client.login() method becoz
in the application login is rewritten.
If I directly use
kwargs = {'HTTP_X_REQUESTED_WITH':'XMLHttpRequest'}
response = self.client.post('/login/', {'username': 't...@test.com',
'password': 'test01', 'domain':'demo1'}, **kwargs)
This works fine but I am not able to test the next url. It's trowing
following error
WARNING:root:Caught an exception while processing permission:
{'content': 'MSHTML', 'name': 'GENERATOR', 'group_name': ''}
ERROR:root:Permission matching query does not exist.
Traceback (most recent call last):
File "/home/sungard/Portals/trunk/django/portal/../portal/auth.py",
line 143, in authenticate
perm = Permission.objects.get(codename = codename)
File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
line 120, in get
return self.get_query_set().get(*args, **kwargs)
File "/usr/lib/python2.6/site-packages/django/db/models/query.py",
line 305, in get
% self.model._meta.object_name)
DoesNotExist: Permission matching query does not exist.
Please suggest.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django Unit Test on urls / views
On Wed, Jul 14, 2010 at 12:22 PM, Pradnya wrote: > Hello, > > I am want to write django 1.1 test case on fedora 12 x86_64. > To test the url I want to session to be persistent so that the next > test can use the same context. I can use client.login() method becoz > in the application login is rewritten. Django-developers is for discussing the development of Django itself. If you have a user query, it should be directed to django-users. Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
