I'm working on a pretty large Django project, which has over 60 different forms layout (can be more than this when needed). I pretty confuse that how can I build all such forms manually??. I've came up with an idea is that I'm gonna store form layout in database and with every new forms, I just need to config in database and then using crispy layout to dynamically generate those forms...
Do you guys have any better ideas?
Thanks
When I worked on a form heavy project I used to rely on mixin.
Try to identify what are the comonly used type of field and create them in mixins.
If it's a lot of them then create some 'base' forms that incorporate certain set of fields.
Then you just have to compose the form you want from the diffrents mixins and bases and add anything specific to the new one you want to create.
Or you could create your own mapping structure for form and store the logic on how to build your form in a JsonField for exemple.
a json containing such thing as name, label, widgets, placeholder, (and whatever you need). It can be really simple or really complex if you have complicated structure...
Crispy-forms has dynamic layouts which may help for this use case.
https://django-crispy-forms.readthedocs.io/en/latest/dynamic_layouts.html
Related
I'm about to create a form in my website made in Django with elements that have complex input types from different plugins (like calendar plugins). Also, I'll be using a Validator plugin which validates the input before submission.
My question is do I need to create forms.py and like model the form or can I just create the form manually? The former seems like a very hassle process. Which one is more efficient and recommended?
As #dmitryro said you can create your forms manually in the templates and then getting in the request. It's recommended to use the forms api provided by Django since it allows you to reuse, validate, and customize your forms.
As to whether or not it is a good practice that depends completely on you but if you are trying to scale an application I would recommend use the forms.
It is good to use Django's built in form.
If we use django's form then we only have to write python code and django will create corresponding html for it. And our code will be short and clean.
I'm working on a Django (1.11.1) app which allows users to request reimbursement for certain purchases. Part of the request form (using django.forms) is an itemized list of purchases. I could, of course, hard code some number of rows into the form and make users submit a separate form if they need more rows. But that seems rather inelegant.
My preferred solution would be to allow users to add rows as necessary via JavaScript, then handle that dynamically in forms. However, everything I've found on the subject relates to situations where the number of elements required can be determined at the time the form is rendered to HTML. It isn't clear to me how to apply such an approach to my situation.
As dynamically adding form elements is extremely common, I'm a bit surprised that such functionality isn't baked into Django already.
By the way, as this is intended to be an incredibly simple app, I don't want a solution that will require a lot of work. If there's no easy solution, it'd be better to just hard-code the form HTML directly into the template.
Of course it is covered by django.
You need to use formset https://docs.djangoproject.com/en/1.11/topics/forms/formsets/
And then in the template you need to add more forms dinamically to that formset, better via javascript. Dynamically adding a form to a Django formset with Ajax
It could result hard to understand all the options that django provides with formsets, but it's quite powerful and the simplest way.
I'm developing a website in Django where many of the sites' models' instances are presented to the user in a standardized format on many different pages. I'd like to avoid redundancy in the template coding by creating standard model instance template code then just inserting it each page where a model instance needs to be displayed.
What is the best practice for creating standardized instance display code, then adding it into many different pages?
There are several ways of accomplishing this...
One is to use an include tag and pass your object to the template. Another, similar approach is to create a template tag to render the object, which is useful if you need to do some extra processing in Python before doing the rendering.
Yet another way is to add an instance method to your model to render itself to HTML (or some other format), much the same way a form instance has .as_ul or .as_p that you can call in your template where needed.
Neither way is right or wrong, it just depends on what you're most comfortable with stylistically and what's most efficient for your needs.
I want to ask you how it will be better to implement: using Sitecore WebForms for Marketers module or in standard .ascx sublayout.
So I need to implement huge form with dynamic dropdowns, date pickers, checkboxes, radiobuttons, etc. This form contains also dynamic adding new controls (see description in attachment above). So is it possible to create this form in Sitecore WebForms for Marketers module or it will be easier to write it as standard form in ascx.
This form will be saved to sitecore database.
Please answer if somebody have already done smth like this.
Thanks.
To my kowledge it isn't possible to do this out of the box with WFFM in Sitecore.
I guess the first question to ask is: do you or your customer want/need to be able to manage forms themselves without developer interaction?
If the answer to this question is yes, then you could try to implement this with WFFM, otherwise it may be easier to just implement as a normal sublayout.
EDIT
One other thing you could also do is to create a form, then use the 'export to ascx' function. You can look at the generated code to see how the data is written to the WFFM database - this way you can have your custom form functionality but still leverage the reporting functionality in the Sitecore client. If you have some decision tree-like logic for displaying the different fields you could probably drive this from Sitecore content items as well.
As per my knowledge you can create this form with the help of Web form for marketer but in this case you need to create some custom fields and update these fields as per your requirement.
To Create custom field create field under /sitecore/system/Modules/Web Forms for Marketers/Settings/Field Types/Custom location and in custom field define your created custom class and assembly.
You can update design by applying your custom css classes.
Class you can create under /sitecore/system/Modules/Web Forms for Marketers/Settings/Meta data/Css Classes location and apply class on specific control.
I want to add a layout model to my website (a general settings file), and I want it to be available in the admin interface for configuration.
class Layout(...Model):
primary_header
logo_image
...
This structure shouldn't saved be in a table.
I am wondering if there is a built-in feature that can help me do this.
Thanks
My use case is a configurable layout of the website. Wordpress style. I would like to store that data in a concrete class, without having to implement the file /xml serialization myself.
What about an abstract model? It does not save in the database and is meant to be subclassed, but you are allowed to create instances of it and use its attributes. I assume you want some kind of temporary data structure to pass around that meets the requirements of a model instance.
class Layout(models.Model):
class Meta:
abstract = True
If you for some reason need actual concrete models, and are fine with it creating tables for them, you could technically also re-implement the save() method and make it no-op.
I don't really understand where and how you will be using this, but this is indeed a model that doesn't save.
Personally, I have actually used models that aren't intended to be saved, in a project that uses mongodb and the nonrel django fork. I create models that are purely meant to be embedded into other models as nested sub-documents and I never want them to be committed to a separate collection.
Update
Here is another suggestion that might make things a whole lot easier for your goal. Why not just use a normal django model, save it to the database like normal, and create a simple import/export function to save it out to XML or read into an instance from XML. That way you get 100% normal admin functionality, you can still query the database for the values, and the XML part is just a simple add-on. You can also use this to version up preferences and mark a certain one as active.