Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with django-components? #86

Open
JuroOravec opened this issue Feb 1, 2025 · 1 comment
Open

Compatibility with django-components? #86

JuroOravec opened this issue Feb 1, 2025 · 1 comment

Comments

@JuroOravec
Copy link

Hi, how easy / hard do you think it would be to either adjust this project (or fork it) to make the language server work also with django-components?

django-components is growing is scope, and my target for it is to make it into a standalone Django "engine" that would supersede the default Django templating engine.

django-component's (DJC) template is a superset of Django templates - DJC will allow literal lists and dictionaries to be defined in place of values (e.g. {{ [1, 2, 3] | my_filter }}). Lists, dicts, and even items within them can have filters applied to them.

Then there's a couple of DJC-specific template tag features that are valid only within DJC's template tags (e.g. {% component %})

I already wrote a Rust-based parser that processes the contents of template tags ({{ ... }} or {% ... %}), and returns their position, their kind, as well as filters and filter args, all as an AST. So it can be easily extended to process a whole template.

Moreover, we designed the template tag definition such that it can be easily picked up by language servers - the end and start tag, as well as tag's signature is declared on a corresponding class.

E.g.

class MyNode(DjcNode):
    start_tag = "my_tag"
    end_tag = "end_my_tag"

    def render(context, name: str, items: list[int], **kwargs):
        ...

Will correspong to use like so:

{% my_tag "demo" [1, 2, 3] %}
{% end_my_tag %}

or

{% my_tag name="demo" items=[1, 2, 3] %}
{% end_my_tag %}

So template tags defined with DJC would also allow to validate the inputs to the template tags, treating them as if they were functions.


Don't know how / if this project handles Django's built-in template tags. Because those built-in tags don't have very standardized behaviour (e.g. the w in {% lorem 3 w %} is a flag in lorem, but w would be a variable in {% if w %}).

So for django-components I'm thinking of re-defining the built-in template tags using DJC's Node class, in order to give the built-in template tags a standardized interface.

I assume that, right now, if this language server handles built-in template tags, it has to do so manually. DJC would make the language server's job much easier when it comes to template tags. Because the language server would only need to run the Django project, and check for all subclasses of DJC's Node. All the metadata would be already there, standardized.

And that means that it would be also easy to support also user-defined template tags, as long as they subclass from DJC's Node class.


@krukas
Copy link
Contributor

krukas commented Feb 3, 2025

Hi @JuroOravec our goal is to support the Django template engine. We would like to add something like contrib/hooks for adding custom completions/gotos for blocks and filters. We are using reqex matching, so I think if we add something like a plugin hook it should be possible to add this features.

Only thing I'm not sure of is how to add hooks to the Django collector script. The Django collector script is a standalone script that is run inside the project environment. Maybe we could generate the script and include the plugin code into one file?

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

No branches or pull requests

2 participants