On Thu, Jan 24, 2013 at 7:06 AM, Mike Dewhirst <miked@dewhirst.com.au> wrote:
Certainly you must have a strategy for dealing with the potential for the limit having changed since the form was displayed, but the use case is still reasonable.
I don't believe that the ability to provide a coded iterable object as the value of choices is going to help, since I don't believe that there is a way for it to access the instance of the model (from which to find the current in stock number).
You could add a method to your class that returns range(1, 1 + self.stock) and use that to control a template "for" tag building your list of html option tags for a select drop down. (range is a python builtin, in case you're not familiar with it.) The problem that I see here is that if row.stock is large, you probably don't want to use a drop down, since it doesn't have comfortable usability for the visitor. You could switch to just providing a text input if the stock is too large, along with a note saying what the limit is.
If you do a text input, you would probably like to validate it before submission (although you will certainly want to validate it in the view as well). When the new input tag attributes of HTML5 become universal, that will be straightforward. But pre-submission validation today requires JavaScript. Even I tend to enable the site's javascript when I'm ordering something on line, so that's a pretty safe bet today. But if you can count on javascript, you can build the select option list and/or validate the text input using javascript as well, if you render a hidden or non-editable input initialized to row.stock. Note that the hidden field gets submitted, so the back end validation can tell whether the available number changed between GET and POST, or whether a non-javascript or firebug using user has entered a number larger than you said was available, just in case you want to provide different error messages for these two cases.
Bill
-- On 24/01/2013 10:30pm, frocco wrote:That would be easy enough (look up range in the Python docs) but I'm not sure what you want to do is a good idea.
Thanks Mike,
Since I am new to django, how would I code this?
In my for loop, my row.stock field has a value.
Lets say row.stock is 20
I want my choice field to show 1 to 20
The next row.stock might have 12
I want my choice field to show 1 to 12
In other words, I do not want the user to select more stock than is
available.
What happens if you present a range from 1 to 12 and while the user is thinking about it someone else buys half a dozen?
Personally, I would be assuming orders will be un-satisfied and re-design to cater for that gracefully. Perhaps you really need a back-ordering system?
Certainly you must have a strategy for dealing with the potential for the limit having changed since the form was displayed, but the use case is still reasonable.
I don't believe that the ability to provide a coded iterable object as the value of choices is going to help, since I don't believe that there is a way for it to access the instance of the model (from which to find the current in stock number).
You could add a method to your class that returns range(1, 1 + self.stock) and use that to control a template "for" tag building your list of html option tags for a select drop down. (range is a python builtin, in case you're not familiar with it.) The problem that I see here is that if row.stock is large, you probably don't want to use a drop down, since it doesn't have comfortable usability for the visitor. You could switch to just providing a text input if the stock is too large, along with a note saying what the limit is.
If you do a text input, you would probably like to validate it before submission (although you will certainly want to validate it in the view as well). When the new input tag attributes of HTML5 become universal, that will be straightforward. But pre-submission validation today requires JavaScript. Even I tend to enable the site's javascript when I'm ordering something on line, so that's a pretty safe bet today. But if you can count on javascript, you can build the select option list and/or validate the text input using javascript as well, if you render a hidden or non-editable input initialized to row.stock. Note that the hidden field gets submitted, so the back end validation can tell whether the available number changed between GET and POST, or whether a non-javascript or firebug using user has entered a number larger than you said was available, just in case you want to provide different error messages for these two cases.
Bill
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment