Multiple models on one form
I am trying to write a custom form that will handle updates for several models. What is the best way to do this? Do I have to write a custom manipulator to handle the data? Or can I create a hybrid view of several different default manipulators? --~--~-~--~~~---~--~~ 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: Multiple models on one form
I am trying to get your solution 1 to work for the case of multiple instances of the same model. The forms looks good, but the problem is that all fields have the same name (because the forms are generated from the same model). Is there any way around that? Or do I have to write a custom manipulator in this case? It seems as if I'm SOOO close... Thanks! On Dec 8 2006, 7:47 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: On 12/9/06, Brian Morton <[EMAIL PROTECTED]> wrote: > I am trying to write a customformthat will handle updates for several > models. What is the best way to do this? Do I have to write a custom > manipulator to handle the data? Or can I create a hybrid view of > several different default manipulators?There are at least two approaches, which you have pretty much suggested in your question. 1) Write your view and construct 2 manipulators, and 2 FormWrappers, and pass them both into the template; on Post, validate and save both manipulators. This is exactly the same as the normal 'edit' view pattern, except that you double up on the use of forms and manipulators. 2) Write a customized manipulator that covers both models, and create a view that instantiates that manipulator. 1 will probably be easier to get going, but requires a sort of code duplication. 2 is more complex, and is ultimately more flexible, Either way, you will need to write your own view. The other thing you might want to look at is the newforms library. Adrian is in the process of developing a replacement for theForm/Manipulator approach. The biggest missing piece is the 'createformfrom Model' aspect, but you are looking to create a customized hybridformanyway. No guarantees, but it might be worth a look. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Multiple models on one form
On 1/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I am trying to get your solution 1 to work for the case of multiple instances of the same model. The forms looks good, but the problem is that all fields have the same name (because the forms are generated from the same model). Is there any way around that? Or do I have to write a custom manipulator in this case? It seems as if I'm SOOO close... I can't think of an easy way to add a prefix to one of the manipulators, so In this case, I think you will need to resort to a custom manipulator. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Multiple models on one form
Hmmm, somehow the django admin interface gets this done (when you add foreign key related fields). It somehow puts an index into each field name. I started digging through the django code, but ... well, I'm just not great in digging through code... On Jan 5, 6:35 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: On 1/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I am trying to get your solution 1 to work for the case ofmultiple > instances of the same model. The forms looks good, but the problem is > that all fields have the same name (because the forms are generated > from the same model). Is there any way around that? Or do I have to > write a custommanipulatorin this case? It seems as if I'm SOOO > close...I can't think of an easy way to add a prefix to one of the manipulators, so In this case, I think you will need to resort to a custommanipulator. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Multiple models on one form
On 12/9/06, Brian Morton <[EMAIL PROTECTED]> wrote: > > I am trying to write a custom form that will handle updates for several > models. What is the best way to do this? Do I have to write a custom > manipulator to handle the data? Or can I create a hybrid view of > several different default manipulators? There are at least two approaches, which you have pretty much suggested in your question. 1) Write your view and construct 2 manipulators, and 2 FormWrappers, and pass them both into the template; on Post, validate and save both manipulators. This is exactly the same as the normal 'edit' view pattern, except that you double up on the use of forms and manipulators. 2) Write a customized manipulator that covers both models, and create a view that instantiates that manipulator. 1 will probably be easier to get going, but requires a sort of code duplication. 2 is more complex, and is ultimately more flexible, Either way, you will need to write your own view. The other thing you might want to look at is the newforms library. Adrian is in the process of developing a replacement for the Form/Manipulator approach. The biggest missing piece is the 'create form from Model' aspect, but you are looking to create a customized hybrid form anyway. No guarantees, but it might be worth a look. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Solution to multiple models on one form?
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 -~--~~~~--~~--~--~---
Re: Solution to multiple models on one form?
On Fri, 2007-05-18 at 00:09 -0700, 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 To be fair (to both David and you), since it's possible the "Django way" includes feeling free to write your own utility methods (a.k.a "it's just Python, after all"), I don't see David's approach as a horrible idea. > 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/ Aargh... my eyes! The colouring scheme on dpaste and the sort of code you're writing there is such a good advertisement for why automatic syntax highlighting is sometimes the work of the devil. Every other word changes colour. Without having read that code in huge details (you get huge bonus points for documentation there, by the way), my gut feeling is that it isn't a crazy approach, although it looks like it might be a little complex. That's possibly a consequence of the amount of customisability you've built in, though. Any code that does introspection on models and wants to be able to follow arbitrary relations and pass the results to arbitrary classes for processing is going to have a few "if's", loops and attribute lookups involved. Introspection code is one of the more complex areas to work in with any language that doesn't equate code and data (cavaet because it feels more natural in Lisp), so don't feel too bad about it feeling a little fiddly. 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: Solution to multiple models on one form?
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? > 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? > > 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? 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: 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 -~--~~~~--~~--~--~---
Re: Solution to multiple models on one form?
On Sun, May 20, David Priest wrote: > > 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. The problem is not that it's about several tables, but that you have multiple records (of unknown quantity) for one of the tables. (Or did I get something wrong?) This particular quest--a form that sends to several tables, with a master-detail relationship--is pretty hard and barely documented with oldforms, either ;-) > I think I'll just hardcode it all, and deal with improving it when > newforms is better documented. Good luck. When you have multiple "detail" records in your view, it's far from trivial. I can only reiterate Malcolm's advice. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
