thymeleaf-extras-eclipse-plugin
thymeleaf-extras-eclipse-plugin copied to clipboard
thymeleaf
Extend dialect scanning to class files
The plugin searches for XML files to draw its suggestions/documentation from. I want to find out if I can extend it to search for implementations of Thymeleaf's Dialect class, and from that gather all the processors from a dialect to build the suggestions list. Obviously there won't be any help/documentation associated with those suggestions, and there also won't be any support for expression object utility methods, but it would be good to get basic content assist support for other dialects whose authors didn't provide an XML help/documentation file.
Nice idea !
Another feedback : once you have the list of processors embedded in a Dialect, maybe the Eclipse API allows to grab each processor's comments/Javadoc annotation, allowing you to automatically associate help/documentation with the suggestions ?
If it's possible, why not propose a pattern in the comments that would be intercepted by the plugin, in order to avoid copy-pasting all the classes comments in the assistant but just some informations ?
There would be no additional workload, as theorically, all classes should be already commented/Javadoc-annotated :-)
Just an idea ;-)
Using the Javadocs of a processor would be the goal. Then all one would need to do is make sure they include the source code of the dialect they're using, which is what Eclipse users do anyway with normal Java projects to get the Javadocs showing for the libraries they use in content assist.
I tried getting the processors from the Thymeleaf standard dialect, but then ran into the problem that the plugin couldn't instantiate the StandardDialect class because Thymeleaf itself isn't on the classpath of the plugin. There may be a way to get around this, but I haven't investigated it yet.
Also, I might need to keep the XML help files for the Thymeleaf standard dialect for now because the Thymeleaf processors have minimal Javadocs on them. If this all works out, I might try convince @danielfernandez to add some more comments to his code :)
Arg, hit a roadblock: I was able to instantiate a dialect class, but on invoking the getProcessors() method on Thymeleaf's StandardDialect, a ClassNotFoundException was thrown because it needed SLF4J (I instantiated Thymeleaf in an isolated classloader). I could load SLF4J JARs as well, but if I continue down this path, the only safe way to guard against ClassNotFoundExceptions would be to load all runtime dependencies of the project, and I do not think this will lead to good things (massive memory usage and very slow plugin performance, especially on larger projects).
So I'll put this idea on hold for now.
I think I can still make the plugin read Javadocs if I introduce some new elements to the XML help files which point to processor classes (I've already got elements for pointing to expression objects) that the plugin can then load and search for the source code, if available. This makes those XML files more like meta data about a dialect, rather than just documentation, which I quite like.
Could this be of help? http://qdox.codehaus.org/
Nah, forget about that. Seems to be too outdated. So the problem is... you need to know the "names" of the processor classes in order to access their javadocs, right?
Hmmm... maybe that could be an improvement for future versions of thymeleaf, adding some sort of method to IDialect like "give me all the names of attributes/tags with processors and the name of their implementing classes"...
The problem is that I can't create and query a dialect instance to ask it for all of its processors because doing so might require loading additional dependencies. (Note: I'm using reflection to load dialect classes because of the classloader separation between IDE and a project.). To resolve those dependencies, I may have to load an entire project into an isolated classloader, and that seems a bit overkill.
I gave this some more thought, and the idea of using annotations came to mind. It feels like a good way to declare the meta-data about dialects / processors / expression objects that the Eclipse plugin needs, without having to resort to writing an XML file. The only problem here is that any annotations should be part of the Thymeleaf core, otherwise it might be a bit strange asking dialect developers to download an annotations package (an additional dependency) just so that their stuff works in the Eclipse plugin.
This might be something to think about in the future.
Doing some spring cleaning of issues, and I'm going to close this one - it's been open for over a decade so highly unlikely we'll get do this 😅