Re: request.POST.getlist('fieldname') / repeated rows of fields
It also appears that a dashed name can cause problems in templates, as it is interpreted as minus sign. On 07-Jun-12, at 5:42 PM, David Priest wrote: > Well, now, that is an interesting find. > > It seems to me the upcoming prefix attribute should result in a > dotted name, not a dashed one, so that one could make good use of > this utility. > > > On 07-Jun-10, at 9:35 PM, SmileyChris wrote: > >> django.utils.datastructures.DotExpandedDict > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: newforms, manytomany, default value.
Lordy, I would dearly *LOVE* for someone to answer your question! On 07-Jun-5, at 6:52 AM, larry wrote: > >> I'm not sure what "a patch in the development tree" means here. >> Current >> subversion trunk doesn't seem to have anything like that. > > Sorry for not being clear -- I'm (obviously) not familiar with the > mechanism of open source / django development. What I was referring > to is the ticket you mentioned (4001) and the "patch" is the file > attached to that ticket (save_instance_m2m.patch). > >> Remember that the situation where a form maps precisely onto a >> model is >> a very specialised case. In the general case, you need to build the >> objects you are going to save manually anyway (since one form >> provides >> information for many models). So the workaround that springs to >> mind in >> this case is to forget about using form_for_model() and just build >> the >> form by hand and construct the save objects in your view. It's only a >> few lines of code. > > That sounds great (in fact, I was forced to combine two tables into > one in order to coerce the data into something that can be easily used > by form_for_model). However, I'm not sure where to start to come to > grips with the concepts of "objects you are going to save", "build the > form by hand", and "construct the save objects". > > I'm guessing that this means instantiating models, creating the form > bound to data from several different model classes, then (on POST) > instantiating new model instances, somehow unpacking the data from the > form into the appropriate model classes, and saving the instances. > > If you can direct me to a simple example of a view that does this > (including a many-to-many field in one of the models if such a field > requires any special handling in the view) it would be greatly > appreciated. I guess my three sticking points are 1) how to create a > form from _several_ objects, 2) how to create the form from several > _models_ when the user is trying to add new information and 3) how to > instantiate the multiple save objects from the POSTed form. > > Many thanks for your kind assistance in what I know must be quite a > simple operation. > -- > Larry Lustig > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: request.POST.getlist('fieldname') / repeated rows of fields
Well, now, that is an interesting find. It seems to me the upcoming prefix attribute should result in a dotted name, not a dashed one, so that one could make good use of this utility. On 07-Jun-10, at 9:35 PM, SmileyChris wrote: > django.utils.datastructures.DotExpandedDict --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: request.POST.getlist('fieldname') / repeated rows of fields
http://code.djangoproject.com/browser/django/trunk/tests/ regressiontests/forms/tests.py#L3055 It turns out that this would be a *considerably* more useful function if I could select which attributes would get prefixed. For most CSS work, one would not want the name to be unique; for most script work, one does want the id to be unique. Right now, both attributes get nailed, which makes them far less useful in distinguishing things 2- dimensionally (by row and by field group). On 07-Jun-11, at 3:21 PM, Malcolm Tredinnick wrote: > > On Mon, 2007-06-11 at 15:10 -0700, David Priest wrote: >> D-oh! Look at this, a recent (?) dev version handles this for me: >> >> self.subforms.append( SimpleItemForm(item, prefix='line_%s' % >> n) ) >> >> This prefixes the IDs for each form field with line_N. (Oddly, it >> then uses a hyphen to separate my prefix. I had expected an >> underscore.) The names come out as line_1-FieldName. >> >> It's then child's play to tell which datum belong to which >> field. :) Happy, happy! > > At the risk of asking a silly question, where did you find that code? > There is no line like that in either trunk or newforms-admin. You > may be > relying on something that isn't in the standard distribution here. > > There will be similar functionality in newforms-admin (and eventually > trunk), but it's not fully implemented yet. > > Regards, > Malcolm > > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: request.POST.getlist('fieldname') / repeated rows of fields
D-oh! Look at this, a recent (?) dev version handles this for me: self.subforms.append( SimpleItemForm(item, prefix='line_%s' % n) ) This prefixes the IDs for each form field with line_N. (Oddly, it then uses a hyphen to separate my prefix. I had expected an underscore.) The names come out as line_1-FieldName. It's then child's play to tell which datum belong to which field. :) Happy, happy! On 07-Jun-10, at 6:10 PM, David Priest wrote: > > request.POST returns a QueryDict object for those fields that have > the same key. The key appears to be assigned by Django when it > magics the form and template into an http response. > > It seems difficult to get Django to deal with multiple lines on a > form, ie. as when creating almost any business form where there's a > single header (names, addresses) and many lines (SKUs, descriptions, > costs, quantities, etc). > > One of the easier ways of dealing with this is to simply use two > forms, one for the header and one for the line item, and then to > repeat the line item a number of times over. Unfortunately, Django > doesn't provide an easy way to differentiate between these lines; the > field ids will all be the same. Munging the field names doesn't > work; that just makes it impossible to refer to them on the template > (variable names aren't dynamic). > > So we seem to be stuck getting lists back. Question is, *is the > order of the list guaranteed*? Which is to say that will the first > items in SKU, Description, and Cost all refer to the same object; the > second items to the second object; and so on? > > And if not, how does one deal with this situation? > > The Admin interface does it. I haven't been able to figure out where > it does it, so I can steal its method... > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
request.POST.getlist('fieldname') / repeated rows of fields
request.POST returns a QueryDict object for those fields that have the same key. The key appears to be assigned by Django when it magics the form and template into an http response. It seems difficult to get Django to deal with multiple lines on a form, ie. as when creating almost any business form where there's a single header (names, addresses) and many lines (SKUs, descriptions, costs, quantities, etc). One of the easier ways of dealing with this is to simply use two forms, one for the header and one for the line item, and then to repeat the line item a number of times over. Unfortunately, Django doesn't provide an easy way to differentiate between these lines; the field ids will all be the same. Munging the field names doesn't work; that just makes it impossible to refer to them on the template (variable names aren't dynamic). So we seem to be stuck getting lists back. Question is, *is the order of the list guaranteed*? Which is to say that will the first items in SKU, Description, and Cost all refer to the same object; the second items to the second object; and so on? And if not, how does one deal with this situation? The Admin interface does it. I haven't been able to figure out where it does it, so I can steal its method... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
A bizarre Forms-via-Templates idea...
Templates can output any textfile we care, right? And django's got this nifty auto-updating thing going, where changes to a file are immediately reloaded into the running application. So... We use forms_for_model to get the fields, put it into a request context, and call a template which outputs a valid Python program containing class myname(forms.Form) definitions. These, in turn, are used to render UI forms for the end-user. It'd require a few django hooks, so as to execute after a models.py file is changed; and to render without needing an http request. Alternatively, I might be crazy to think this is feasible. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: WANTED: Demonstration of good FK & M2M form creation
On 07-May-21, at 5:56 PM, Malcolm Tredinnick wrote: > It sounds like you want the django.newforms.formsets capability that > isn't on trunk yet. > > A little more patience will be required. Is this patience measured in days and short weeks, or in long weeks turning to months? I need to decide whether I do it all by hand right-this-moment, or delay until I can use the new newforms capabilities... I'm loving where Django is heading. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
WANTED: Demonstration of good FK & M2M form creation
I believe I have performed exhaustive research on the challenge of
creating forms that incorporate fields from multiple tables. I have
not found *any* comprehensive, best-practices examples of this problem.
It really quite surprises me, as any web application of even moderate
complexity requires multiple tables.
Anyway, I think everyone (and especially all us n00bs) would *really*
appreciate a good bit of demonstration code for the following sort of
scenario:
class Customer(models.Model):
name = models.CharField()
phone = models.PhoneNumber()
class Rentals(models.Model):
title = models.CharField()
serial = models.Integer()
rented_to = models.ForeignKey(Customer)
rental_due = models.DateField()
The Form should display the customer's name, phone number, and the
movies the customer has rented, but *not* the date they're due
('cause I'd like this problem to represent real-world problems, where
one doesn't necessarily display all the fields for editing).
I've been battling at this for days, reading a lot of newsposts and
websites, and I've come up with bupkiss. It is extraordinarily
frustrating.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Solution to multiple models on one form?
On 07-May-18, at 6:33 AM, Malcolm Tredinnick wrote: > > On Thu, 2007-05-17 at 20:08 -0700, David Priest wrote: >> It occurs to me that were I able to write the following: >> models_list = ( >> 'project.app1.models.Claim', >> 'project.app2.models.Vendor') > > Why is this needed? Couldn't you require that the fields_list strings > are python access paths referring to things that are already imported? Hey, if that's possible, so much the better. >> fields_list = ( >> 'Claim.vendor', >> 'Task.title', >> 'Task.description', >> 'Claim.claimed_cost', >> 'Claim.outcome', >> 'Claim.credit') >> __metaclass__ = MyMMF > > What does the metaclass do? Is this a replacement metaclass for the > Forms metaclass? A replacement metaclass for MetaModelForm.py or WTFForm or so on. Seems to be the common way of accomplishing this sort of functionality. How they actually work remains opaque to me. >> I could have a class that would go through fields_list and snarf down >> form fields from the models, akin to the process used by >> forms_for_model and forms_for_fields. >> >> The format I give above indicated the field ordering, which is quite >> handy; and tells the metaclass from which model classes to grab the >> fields. > > Now I'm really confused by the metaclass's purpose. If you're doing > something similar to forms_for_model aren't you wanting to create a > function (or class __init__() method, most likely) that takes the list > of fields and returns a Form subclass? Honest to god, I've no idea if metaclasses are the right way to do it. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Solution to multiple models on one form?
After bashing at it some more, I had to conclude I was out to lunch. It is killing me to wait for newforms. It's senseless for me to learn old forms, but I'm having a helluva time making heads or tails of newforms. Some things that I swear must be common as mud -- like a form that sends to several tables (ye olde address vs purchase order scenario) -- seems far, far too difficult. I think I'll just hardcode it all, and deal with improving it when newforms is better documented. On 07-May-18, at 12:09 AM, Doug B wrote: > > My suggestion would be to NOT implement it! I took a similar approach > when I was trying to learn python/django, wasted a bit of time, and > almost never use the monstrosity I created. I'd have been better off > just doing it the django way and/or waiting for newforms to be > completed (which may break my implementation anyway). > > However, looking at my mistake may give you enough info to make your > own! > > (it works, but should really have been a metaclass... but didn't know > anything about that at the time). > > http://dpaste.com/10566/ > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Solution to multiple models on one form?
It occurs to me that were I able to write the following: models_list = ( 'project.app1.models.Claim', 'project.app2.models.Vendor') fields_list = ( 'Claim.vendor', 'Task.title', 'Task.description', 'Claim.claimed_cost', 'Claim.outcome', 'Claim.credit') __metaclass__ = MyMMF I could have a class that would go through fields_list and snarf down form fields from the models, akin to the process used by forms_for_model and forms_for_fields. The format I give above indicated the field ordering, which is quite handy; and tells the metaclass from which model classes to grab the fields. What I lack is sufficient ju-ju to make it work. My hope is that some Very Smart Person can implement this. Or, at least, provide some pointers on how to do it. I suspect it involves some introspection magic, which so far has completely evaded me. Thanks in advance! david --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
