Closed yuriescl closed 4 years ago
The instructions_for_pending_deposit()
integration needs upgrading. There should be a better interface for providing instructions within the more_info template.
In the immediate future, you can use Polaris' JS script integration. Using this integration you can solve your issue a number of ways better described here.
Any changes to instructions_for_pending_deposit()
will be included in a post-v1.1 release. I'm wondering if we should replace the text/html
content returned with a Django Template object.
The idea is the Polaris dev would load a HTML Template source file into a Template
django object and return it. Tags can reference CSS style groupings defined from a JS script passed via the JS script integration function mentioned above.
If you don't like the idea of returning TemplateScript
objects from the JS script integration function and would rather just replace Polaris' CSS styling altogether, see how Polaris allows developers to override the base CSS stylesheet used.
I'm wondering if we should replace the text/html content returned with a Django Template object.
Yes. Polaris could support str
and Template
. If it's str
, it treats as plain text and inserts it into more_info.html
(same as currently). If it's Template
, it renders the template instead of more_info.html
.
With that change, I would create a template and inherit it from more_info.html
.
Polaris could, in the base template, add {% block extra_head %}
and {% block extra_body %}
to the end of <style>
and <body>
tags respectively, so new templates could easily add their own template-specific styles and scripts without having to override styles.css
or adding global JS using the JS integration.
If it's Template, it renders the template instead of more_info.html.
The template returned wouldn't replace more_info.html, it would be inserted into it in the same way the text or HTML is inserted today.
See how Polaris' deposit template is loaded into the base template.
If it's Template, it renders the template instead of more_info.html.
The template returned wouldn't replace more_info.html, it would be inserted into it in the same way the text or HTML is inserted today.
I see.
But still, inserting custom CSS (including a new CSS file, for example) should not be difficult. Right now it would require either using JS or overriding styles.css
entirely, correct?
Just adding the extra_
tags would make it far easier to write new templates. This would maybe even remove the need for a JS integration since the the developer could just inherit base.html
and just add his <script>
tags inside extra_body
.
But still, inserting custom CSS (including a new CSS file, for example) should not be difficult. Right now it would require either using JS or overriding styles.css entirely, correct?
Thats correct. You can override base.css
entirely but you can also just make a copy and build/modify it.
Lets clear something up about how the Template stuff will work for instructions_for_pending_deposit()
.
You are not going to be writing your own Template that inherits from base.html
, you'll be writing a Template that is rendered within more_info.html
.
When instructions_for_pending_deposit()
is called, a Template
object will be returned instead of text. This instructions_template
will be rendered within more_info.html
like so:
% block "content" %}
<section class="section receipt">
{% if instructions_text is not none %}
<div class="info-item">
<div class="info-label">
{% trans "instructions" %}
</div>
<div class="field-value">
{{ instructions|safe }}
</div>
</div>
{% if instructions_template is not none %}
{% block "instructions_template" %}
{% endblock %}
{% endif %}
This instructions_template
will contain rendered HTML code to insert into that page. See the more_info.html
page to get a better understanding of how it works today.
The JS script integrations will likely not be removed. It is important to load JS scripts defined by the anchors within the body of the HTML doc, not the head. Thats why it makes more sense to provide a new integration that allows Polaris developers to put custom CSS link
tags in the <head>
tags, separate from the <script>
tags loaded by the JS integration at the bottom of the body.
Understood.
I'm not sure if I agree with managing CSS/JS inside Python code (integration functions). That's why I was suggesting the {% extra_head %}
and {% extra_body %}
tags and so on.
There should be a better way of doing this, I'll get back to you if I have any ideas regarding that.
Actually, we can do this today via content_for_template()
. I could allow a stylesheets
key that would map to a list of Polaris TemplateLink
(think CSS TemplateScript) objects. These TemplateLink
objects would contain the file paths to the CSS source files listed in their static directory and be rendered as <link href=../>
in whatever template is being rendered.
So to review, there are two separate issues being discussed here:
Hopefully both of these issues are resolves by:
stylesheets
key to content_for_template()
and TemplateLink
object, which should allow you to add CSS to the head of the HTML doc per-page displayed.instructions_template
variable to the more_info.html
template that will contain rendered HTML content passed as a Template
object by the developer from instructions_for_pending_deposit()
Looks like I didn't see this comment before posting the 2 comments above, does my improved solution make sense?
Here's an idea:
Modify base.html
by adding extra_head
and extra_body
tags:
...
background-repeat: no-repeat;
background-position: right 1em top 50%, 0 0;
}
</style>
{% block extra_head %}
{% endblock %}
</head>
...
{% endif %}
{% endfor %}
{% block extra_body %} {% endblock %}
When returning HTML from
DepositIntegration.instructions_for_pending_deposit
, I'm having to use inline CSS inside the tags, as I couldn't find an easy way to define custom CSS for Polaris templates. Polaris has an integration function to define custom JS, it would be great to have something similar for CSS as well.UPDATE: This issue now is about two things:
The two integrations that serve the purpose template extensions can do better are:
content_for_template
also returns data for templates but its content that must be sent from the backend, not computed or processed on the frontend.