Skip to content
This repository has been archived by the owner on Sep 18, 2022. It is now read-only.

Deprecate HTML() in favor of TemplateInclude() #101

Open
phretor opened this issue Sep 23, 2011 · 1 comment
Open

Deprecate HTML() in favor of TemplateInclude() #101

phretor opened this issue Sep 23, 2011 · 1 comment

Comments

@phretor
Copy link

phretor commented Sep 23, 2011

The HTML() element is dangerous because it goes beyond the boundaries of clean Django/Python coding and, more importantly, it has nothing to do with the layout stuff.

We all know it comes very handy sometimes when you have to add a small piece of text, but one day one could be very well type HTML("<input ... />").

I propose the following:

  • remove HTML() and replace it with Text("hey daddy!", attrs={'class': 'foo'}) (which renders to <p class="foo">hey daddy!</p>)
  • introduce TemplateInclude("foo/snippet.html") that does exactly what it says, it adds the equivalent of {% include 'foo/snippet.html' %} during template rendering.
@maraujop
Copy link
Collaborator

Hi Federico,

I think having a TemplateInclude layout object is a good idea and something I have been postponing for a while because there were a lot of things to do before. So I'm in favor of adding this layout object. Not sure about the name, I'm awful at naming things, @pydanny has a knack for this, so he probably wants to confirm if he agrees or not.

On the other hand, deprecating HTML is a big movement and would force a lot of people that use it to put a lot of work to update their code.

I'm actually in favor of having it around for little snippets of html I add to my forms. Things like:

HTML('<span class="hidden">Data saved</span>')

Sure I understand some people might be misusing django-uni-form, but sometimes there are limits to the path you can show to the user. I think django-uni-form already does a great job at showing best practices.

Consider that removing HTML would mean adding templates for every little piece of html. This slows down development, reduces performance of the form (template loading is quite expensive) and adds a lot of maintenance work. I would use TemplateInclude for big chunks of template code and maybe some people for small chunks, but let's let the people chose what they want, instead of force them.

Sometimes breaking DRYness or code separation, I know having html inline within Python code is not the most elegant thing on Earth, is worth the overhead of over-engineering.

About Text layout object. I have this rule of thumb "Only add layout objects that do something else you cannot do with the ones we already have". Sometimes this rules has exceptions, but we cannot add a layout object for every html tag out there, I better keep it simple.

Let me know what you think, cheers
Miguel

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants