How to prevent Satchmo forms from displaying asterisk after required fields? - python

I'm customizing my Satchmo store forms and have an icon that appears before any required fields. The problem is, Satchmo seems to want to render a text asterisk after the required fields. I'm using field.label to get this label, should I be using something else?
EDIT: All my form templates are hard coded. I have an inclusion tag that takes a field and wraps it in a standard field template I've developed. My template uses the {{ field.label }} to display the friendly name of the field. It seem the label itself has a single asterisk in it at the end.

What happens if you do the following?
Copy some or all of Satchmo's form templates to a new location and modify them to remove the asterisks
Arrange it so that your copies of those templates are seen before Satchmo's copies (by configuring the template loader settings appropriately, say by placing the app with the copied templates above Satchmo in settings.INSTALLED_APPS)
Update: I'm not able to reproduce your results with a vanilla Satchmo 0.8.1 installation. Can you give some more information? Here's what I did: First, I modified templates/contact/update_form.html, which contains hard-coded asterisks. I could easily remove them by changing the template; they disappeared from the UI. Instead, I left them in but added immediately after, in parentheses, {{ form.field.label }} after each of the fields in a section of the form. This is the result:
The labels here do contain an asterisk - as I mentioned earlier, this is because ContactInfoForm hardcodes this behaviour in its __init__ method. You would have to undo this behaviour, perhaps by using a derived class which removes trailing *s from field labels.
However, I did not find any *s appearing in other required fields. For example, here's a screenshot of the checkout form when I tried submitting without entering required information:
As you can see the credit card number and CCV are required fields but do not appear with an asterisk at the prompt. Nor do the labels have asterisks. So, the problem you are experiencing appears to be something to do with your customisations, but without more information it is difficult to be more helpful.

Related

Define multiple templates for a predefined block wagtail CRX

I was moving a site over to wagtail and decided to use the codered extensions. The library comes with a image-gallery content-block. I want to use this but define a few templates you can choose from in the admin UI.
You usually define a template in the meta section, but I noticed a dropdown in the admin UI for a template.
How do I add a template to that dropdown? Link to the content block I want to change
I am interested in adding an HTML template and not inheriting from the content-block to change behaviour. (Unless inheriting is the only way to add a template to the dropdown.)
You could paramatise the path to the template you want to use then use an include in your block template to point to the chosen one.
For example, if you had a card block with selection for vertical or horizontal format. In your card block class you might have an property named template that uses a choice block, something like
class AlignmentChoiceBlock(ChoiceBlock):
choices=[
('blocks/flex/vertical_card.html', 'Vertical'),
('blocks/flex/horizontal_card.html', 'Horizontal')
]
Then in your block template, it just consists of:
<div class="some-block-container">
{% include value.template %}
</div>
Well, this works for Wagtail at least, not sure about codered.
The answer from Richard Allen works wagtail and is perfect for your own blocks etc. Wagtail blocks define a separate field that is used for their included components, for this you need another approach.
First you need to add the CRX_FRONTEND_TEMPLATE_BLOCKS to your django settings mysite/settings/base.py.
Then create a folder for your block templates in mysite/website/templates and create a custom template. Then add this path as a entry to the CRX_FRONTEND_TEMPLATE_BLOCKS. Entry key should be the block in lowercase. For a starter you could copy a template/html file from the codered package, found in coderedcms/blocks/
Now the template should be available from the template dropdown under the advanced menu of a crx block.
This info came from a gh issue of crx. This is e pretty recent addition and the dev mentioned that they are looking to make this easier. So this might change in the future, this worked for me on 26/01/2023.

Too many templates in Django

I am learning Django and I programming a CRUD for various objects. Currently I need to generate three templates per object: one for creation, one for update and one for a list. Look at how many templates I got in the picture.
The process is becoming painful.
What I am doing wrong and how to correct it?
Thanks.
From your comment:
The problem is that If I need to make a change, for example, add a new button, I have to make it in all the templates.
That sounds wrong. Either a button belong to one type of thing and then it should only exist in that template, or it should be on every page and then it should be in the base template.
You can make one template with your basic page layout (including such buttons), and have "blocks" in them that are then filled out by each template that extends the base template.
See the Django documentation about template inheritance.
Also, I think that in most cases the "create" and "update" pages are going to be extremely similar; usually they use the same template, one with data already filled in, the other without.
You could have a base template, then a generic list template and a generic edit/create template, with templates for each type of thing extending the list and the edit templates to fill in only the relevant fields.
Also, maybe you use HTML that is close enough to what the Django forms can render themselves. Then as long as you call the edit/create form the same in each of your views (like "form"), the template can just render the form and they can all use the same template.
If you're building a big web-app then this is normal for templates to be more.
Heavy (big) web-app means = more templates + more code + more time + more features

Is it bad to design form layout in forms.py Django?

I'm new to Django. After few weeks learning, I've designed my form layout inside forms.py, like this:
But it's quite annoying when I have to write html tag in string format without IDE styling, So do you guys have any ideas to design form layout in Django that is more clear and easy to maintain? I'm using crispy_forms btw.
Thank you...
It's not bad as there are no ways to tell whether practices are good or bad as they're mostly up to personal flavor. My take, however, is that crispy forms do not provide enough flexibility. Plus, once you moved on to complex form controls, you need multiple divisions and the hierarchy will be stacked.
It's up to you whether you want to keep this, but I'll tell you how I get past the forms.
I render the form, no styling, and anything. I then inspect the page and then note down the id, name, field type (autocomplete, required, etc.) of every input as Django needs those to tell your data apart from others.
I don't directly load the form like {{ form.as_p }}. I include the action, URL, and then apply my custom form but use the id, name, and everything else that the default form uses.
So you'll have the same Django field attributes but they are applied to your custom HTML form. It's definitely more work, but from my experience, this pays off.

Building a generic block-based CMS with Django

A designer recently handed me designs for a site I'm building for a client. They're great designs but I'm really scratching my head as to how I'm going to implement it on the site.
The content can very easily be broken down into blocks or chunks of data where I could allocate a textarea for text input, a couple of charfields for link-buttons, etc and sequentially render them out to the page.
The problem (eg why I'm not just pulling in Django-CMS et al) is the blocks are quite unique from each other. There are perhaps 20 different models that I would build for each block type. Rather than hack around a pre-fab CMS, I'd like to build a Page model and then just have an M2M that links to an ordered list of subclasses of my abstract Block class. I hope I'm not losing you.
I don't understand how I can do this. These questions spring to mind:
Is there a simple CMS that does all of this already? Am I wasting my time trying to figure out the physics?
My Blocks subclasses will technically be different type. Do I need generics for a M2M-through class to link to them? Is so, how do I do that?
How do I render x different forms in an inline admin context? (I'd like to have the page form with a list of the Blocks underneath)
How can the user specify the type of Block in the inline control?
Edit: Or, alternatively, what about a templatetag-based CMS?
I'm thinking of something like plonking this in my template:
{% editable 'unique_id' 'content-type' %}
A further example:
{% editable 'home-intro' 'text' %}
Then I could just stick these around the templates I want to be editable, in the way I want them to be editable and when logged in the client would see "Edit text", "Edit link", "Edit image" links which simply popped up the right field.
This would make things more locked down but the layout needs to remain solid (and the client knows nothing about HTML/CSS) so it's one or other of these methods IMO.
Couldn't you implement your 'Blocks' as Django CMS Plugins? Then each page is just constructed from a number of plugins.
Each plugin has an admin form which gets the specifics for itself, and then the page template renders the plugin as you want it.
If you look at the first page of the django-cms demo:
https://www.django-cms.org/en/tour-demo/
you'll see in (1) a highlighted plugin block - in this case a formatted text block that is edited with TinyMCE or similar. You can define your own plugins and add them to pages.
last month I published an article (for review) on how tho build a basic CMS for Jinja. This's templating language does not dffer very much from Django, which I have been using before.
You can find it here. It uses template inheritance to fill the content blocks.
https://codereview.stackexchange.com/questions/5965/review-request-jinja-cms-for-energiekantoor-nl-on-google-app-engine
Or type in Google : Jinja CMS

How can I have attributes that get extracted for i18n in ZPT macros?

I'm using Pyramid with ZPT templates to make a web app. I'm attempting to make a form template macro library to make life easier for things like setting current values of form fields, etc. I'm also using the lingua message extractors to automatically pick up strings for localization. I can't figure out how to make the extractors work with attributes on macro tags though. For example, say I have a macro that looks like this:
<tal:block metal:define-macro="text">
<input type="text" name="${field}" value="${request.params.get(field) or default_value}"/>
</tal:block>
And I use it in a page template like this:
<tal:block tal:define="field 'fred'; default_value _('initial value')" metal:use-macro="form.macros['text']"/>
The text "initial value" won't get picked up by the message extractor. Is there a way to make this happen? I'd like to keep the strings inside the template if possible, I know I could work around this by having all the strings for default values generated in the view callable. Maybe there is there a better way of passing values to macros for use in attributes?
You need to use [lingua] to version 2 (or later) to extract messages from templates for this to work.

Categories

Resources