You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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?
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.
Will correspong to use like so:
or
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 inlorem
, butw
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.
The text was updated successfully, but these errors were encountered: