I believe that the forms obey the order of the "fields" property of the Meta class within your Form class. So if you were overriding a given form you could do this:
*class FooForm(models.ModelForm):* * ...<code>...* * class Meta:* * fields = ( 'myfield1', 'myfield2', ... )* And the fields would be ordered as they appear in the tuple/list. If you look at [cartridge] AddProductForm, you'll note that __init__ treats the fields like a dict. This is because it inherits from [django] Form, which inherits from [django] BaseForm. At the end of the initialization of BaseForm it calls *self.order_fields( self.field_order if field_order is None else field_order )* where field_order is either already present or passed into the constructor. In this function it sets up an OrderedDict. My suggestion is to modify [cartridge] views.py, and pass in field_order after inspecting the object. This behavior appears to be new in Django 1.9. Source: https://docs.djangoproject.com/en/1.9/ref/forms/api/#notes-on-field-ordering On Tuesday, June 14, 2016 at 2:30:22 AM UTC-7, Tran wrote: > > Thanks Ryan. > > I followed the blog again and it works now (I switched the approach > similar to the blog's suggestion). I found the blog earlier but encountered > the error "AppRegistryNotReady("Models aren't loaded yet.") " whenever I > put "from cartridge.shop.forms import AddProductForm" into my > apps/models.py. People also encountered this error in the comment and on > the internet (usually with version 1.8 or above), so one way to temporarily > fix this is to move all monkey patch from models.py to the shop source code > page_processors.py. > > Also, do you know how to make inject the fields in "EXTRA_MODELS_FIELDS" > to be after the default fields defined in the source code. Right now, all > of my injected fields are on top and I prefer to have them after the > default fields. > > On Monday, June 13, 2016 at 2:42:04 PM UTC-6, Ryan Hewitt wrote: >> >> Tran, >> >> I'm in a similar situation except that I have to add fields to an order >> that will actually affect the pricing. I'm still trying to decide on a >> good approach. >> >> Your use case appears to be more straightforward and I would recommend >> reading this blog: >> http://bitofpixels.com/blog/collecting-additional-information-on-a-per-product-basis-in-cartridge/ >> >> In the post he explains that you need to modify Product, CartItem and >> OrderItem, perform a migration and integrate it by modifying the product >> form templates. To tie everything together he overrides the cart and the >> order add functions, as well as the setup function for Order. >> >> I feel this approach is a hack and is resistant to upstream change. >> Unfortunately it appears to be the Mezzanine way and I don't have enough >> e-commerce experience to contrast it to other systems. Please update the >> thread based on your experiences - especially if you encounter a better way >> to make such customizations. >> >> - Ryan >> > -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
