@oliverhaas If you're interested in that, have a look at https://github.com/JuroOravec/alpinui/blob/main/packages/django-expr/README.md :) By default it doesn't allow function calls, but that can be configured via EXPR_ALLOW_FUNC_CALLS

Is the django-cotton style possible yet? Thanks

@aehlke Not yet, but with the addition of extensions, we're getting closer. But there's still a few blockers:

• Fixing the support for literal lists and dictionaries within templates and migrating the parser to a Rust script.
  • I was working on this before getting side-tracked with the performance-related issues. I reckon I'll get back to it in 1-2 weeks.
• Clean up how django-components handles and loads Templates.
  • Right now it feels like a bit of a mess. This is where we'd add an extension hook to pre-process templates, and this is what will make the django-cotton style possible.
  • It's all a bit more complex and intertwined:
    1. When a component's template is defined as a file path or as inlined string, those cases are simple - we just load the content as plain string, and we can pre-process that.
    2. Components also support get_template_name() and get_template() (which IMO I would deprecate and remove in v1). These two make the implementation harder, because it means that each time a component is rendered, it may have a different Template.
    3. And so, when the template is defined as a file path or as an inlined string, we can pre-process the template only once, on the first use of the component
    4. But when using get_template_name() and get_template(), the same pre-processing will have to be called on each time the component is rendered. Alternatively, we could say that the pre-processing would NOT be applied when using these methods, to encourage people to use Component.template and Component.template_file instead.
    5. So that's why I want to first clean up the logic surrounding the templates first.

After these, it will be possible to write an extension that would pre-process the templates.

And as always, if you want to see some features sooner, be sure to support this project!

@aehlke Thanks for letting us know that this is something you would want. Is this a reason to move from django-cotton to django-components? Do you have a project in mind for migration?

@EmilStenstrom just evaluating current django landscape as I prepare to resume working in it after several long years. not a current user of this or cotton. thanks

@JuroOravec
It's not much, but with html-tag syntax I at least get intellisense for css classes:

@oliverhaas So the reasoning is "since my home-make components are very close to native HTML tags (your button component), seeing <c-button> looks natural"? The thing I think might trip people up is not understanding what's going on by looking at the code. What <c-button> does would then depend on which plugins are loaded, what JS libraries are loaded (it could be a normal web component), and many other things. So my reasoning is that this might feel right for someone that knows what they are doing, but is likely to confuse everyone else.

Intellisense and autoformatting for templates would be awesome :)

Btw, @oliverhaas, you mentioned that

We've already started implemented something along those lines in one of our projects to try it out.

Does it mean that you are using django-cotton, or that you implemented your own script that converts the custom HTML-tags to django tags?

For context, I agree with @EmilStenstrom that this should not be in the core package. I was thinking about the plugins for django_components, and realized that they would have to operate on the level of Templates, not a raw string content.

So the options for you would be to:

1. Define a Django Loader that pre-processes the file content, converting the <component /> HTML tags to django_components tags {% component ... / %}, and returning a Template

2. Define a django_components plugin that would be given a Template, and would do the same pre-processing on the template's source content (Template.source), and then re-generate the Template.nodelist.

Of the two, the Loader would be probably a more complex one. Because I can imagine that, to make it work generally, one might have to use similar approach to the cached Loader, nesting other loaders in it:

 'loaders':[(
    'path.to.loaders.Html2DjangoLoader', [
		# Nested
       'django.template.loaders.filesystem.Loader',
       'django.template.loaders.app_directories.Loader',
		...
    ]
 )],

Whereas for the plugin, it would be just a matter of defining a function that modifies the Template in place.

So if you have the logic for converting HTML to django written down, then it should be easy to set things up once plugins are supported.

@JuroOravec Here is our proof of concept, which is basically what you said: A custom template loader which does some parsing, and then just uses django-components like normal. It's heavily inspired by django-cotton. Maybe it leads to something useful...

I think that's it for now from my end.

Thanks for the discussion, and all the good work of you two.

Since this discussion happened, I've been convinced by the popularity of django-cotton that this is something that people really want. I think Juro's idea of implementing this as an optional extension is a nice way of letting people get the cookie or eat it, whichever they want.