madrapps / handlebars-support Goto Github PK

.. child of HpPath should move the context one level up in the parent.

http://handlebarsjs.com/#paths
Nested handlebars paths can also include ../ segments, which evaluate their paths against a parent context.

<h1>Comments</h1>

<div id="comments">
  {{#each comments}}
  <h2><a href="/posts/{{../permalink}}#{{id}}">{{title}}</a></h2>
  <div>{{body}}</div>
  {{/each}}
</div>

Even though the link is printed while in the context of a comment, it can still go back to the main context (the post) to retrieve its permalink.
The exact value that ../ will resolve to varies based on the helper that is calling the block. Using ../ is only necessary when context changes, so children of helpers such as each would require the use of ../ while children of helpers such as if do not.

{{permalink}}
{{#each comments}}
  {{../permalink}}

  {{#if title}}
    {{../permalink}}
  {{/if}}
{{/each}}

In this example all of the above reference the same permalink value even though they are located within different blocks. This behavior is new as of Handlebars 4, the release notes discuss the prior behavior as well as the migration plan.

each is done.
So add support for:

1. All other blocks : unless, if, with
2. For SimpleMustache like {{one.two.three}}
3. For Custom Helpers like {{something one.two}}

this and .. should not be shown in autocompletion, but autocomplete should be invoked after this. and ../

Currently we show suggestions like value, hash which are fields in String class.

Don't show completion suggestions for fields of String, List, Map, and may be some other thing.

After install and restart, it crashes the IDE. The IDE is forced to disable the plugin.

Plugin 'com.madrapps.handlebars-support' failed to initialize and will be disabled. Please restart Android Studio.

java.lang.ClassNotFoundException: com.madrapps.handlebars.HbProjectComponent
             PluginClassLoader(plugin=PluginDescriptor(name=Handlebars Support, id=com.madrapps.handlebars-support, descriptorPath=plugin.xml, path=~\AppData\Roaming\Google\AndroidStudioPreview2021.3\plugins\handlebars-support, version=0.2.0.2021.3, package=null, isBundled=false), packagePrefix=null, instanceId=89, state=active)
    at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass(PluginClassLoader.java:235)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
    at com.intellij.serviceContainer.ComponentManagerImpl.registerComponent(ComponentManagerImpl.kt:437)
    at com.intellij.serviceContainer.ComponentManagerImpl.registerComponents(ComponentManagerImpl.kt:372)
    at com.intellij.serviceContainer.ComponentManagerImpl.access$registerComponents(ComponentManagerImpl.kt:56)
    at com.intellij.serviceContainer.ComponentManagerImpl.registerComponents(ComponentManagerImpl.kt:253)
    at com.intellij.openapi.client.ClientAwareComponentManager.registerComponents(ClientAwareComponentManager.kt:63)
    at com.intellij.serviceContainer.ComponentManagerImpl.registerComponents(ComponentManagerImpl.kt:227)
    at com.intellij.openapi.project.impl.ProjectLoadHelper.registerComponents(projectLoader.kt:25)
    at com.intellij.openapi.project.impl.ProjectManagerImpl.initProject(ProjectManagerImpl.java:177)
    at com.intellij.openapi.project.impl.ProjectManagerExImpl.prepareProject(ProjectManagerExImpl.kt:340)
    at com.intellij.openapi.project.impl.ProjectManagerExImpl.access$prepareProject(ProjectManagerExImpl.kt:56)
    at com.intellij.openapi.project.impl.ProjectManagerExImpl$doOpenAsync$1.invoke(ProjectManagerExImpl.kt:123)
    at com.intellij.openapi.project.impl.ProjectManagerExImpl$doOpenAsync$1.invoke(ProjectManagerExImpl.kt:56)
    at com.intellij.openapi.project.impl.ProjectUiFrameAllocator$run$progressRunner$1.apply(ProjectFrameAllocator.kt:94)
    at com.intellij.openapi.project.impl.ProjectUiFrameAllocator$run$progressRunner$1.apply(ProjectFrameAllocator.kt:71)
    at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:244)
    at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:188)
    at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:624)
    at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:698)
    at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:646)
    at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:623)
    at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:66)
    at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:175)
    at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:244)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

Types like Int, Boolean are not properly referenced. This is because we try to Typecast all Type to PsiClassReferenceType. But Boolean is of PsiPrimitiveType.

this is not supported now. Add support for it.
this should point to the Field and not the the Type. This is because in a Class there could be multiple fields with the same Type. So I believe it's better to show the Field instead of Type.

Each block resolves to only List and Map. I guess we should show Set and may be other collections. Go through Handlebars docs and see what's all are allowed.

Add tests for auto completion suggestion.

1. Ensure we show the right suggestions at the right place,
2. We don't show any unwanted suggestions (show only the right suggestions)
3. Don't do a text comparison, but perform a PsiElement comparison. Because two elements can have the same Name, but we want to make sure we are showing the right element.

val animalsNotEmpty: Boolean
	get() = animals.isNotEmpty()

In the above case animalsNotEmpty is not returned in PsiClass.allFields.

We need to do these instead:

(group?.psiClass as KtLightClass).kotlinOrigin.findPropertyByName("animalsNotEmpty")
(group?.psiClass as KtLightClass).kotlinOrigin.getBody().properties
(group?.psiClass as KtLightClass).kotlinOrigin.getPrimaryConstructorParameterList().children[0]

Test FindUsages for all the fields in the Kotlin class, and assert the number of usages in .hbs

Right now we have to configure each hbs files one by one.
But there might be some logic based on which some projects can configure these in batch. So add an extension point so that clients can make use of that and write their own plugin.
The extension point should enable the clients to batch configure the hbs files with Java/Kotlin classes.

Go through this first: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360001231359-Kotlin-FindUsages-not-working-for-Primary-constructor-for-custom-reference

As you can see, since we resolve to PsiField all the time, we are not fully connecting the Primary Constructor (KtParameter) with the HBS element. So resolve to proper PsiElement.

This should fix the FindUsage for parameters in Primary Constructor

Let's say we have a List<Animal> animals, and then Animal has a field animalName. Now the below is getting resolved by the plugin:
{{animals.animalName}}

But animalName should not be resolved. The problem is because we return Animal as type when we resolve animals instead of List.

This needs to be fixed.

1. Add references between hbs fields and corresponding fields in the mapped class
2. Add support for Renaming
3. Add support for Auto completion

class WildLife() {
    class Animals(val name: String) {
        
    }
}

The parameter name has a one way reference. We can get to this field from HBS file, but can't view the usages in HBS file from the KT file. However, if we move the class Animals outside WildLife, it works perfectly.

New version of plugin 0.1.3 to support intellij 2018.3 version

1. Add the NotificationPanel, and give options to Configure and Ignore. Show the Panel only if the user hasn't already configured, or if not ignored.
2. Tapping on Configure should show a Class chooser dialog.
3. On successful Configure, the mapping between HbsFile to Class should be persisted.
4. Tapping on Ignore, should close the panel and not show again.

Currently we show fields of String type as a suggestion for each. But each only accepts collections like List, Map, etc...
So show only these in the auto completion suggestions.

When you are scopes like ../../name etc.. and do an auto completion for name, there are duplicate entries for name.
This is because we do a full depth search for all fields in all the classes. There might be name in more the 2 classes. We list them all. This should not be the case, since only one of them makes sense.
Remove these duplicates.
Don't simple remove the duplicates based on the PsiNameElement.name, rather remove based on the depth search. (this is because the user can still tap Ctrl + J and look at the Text of the whole element. Here we need to show the right one)

Add tests for references for all mustache elements in .hbs file.
Check for elements with and without reference.

Let's just see how autocomplete works and get the resolution code ready for it using each as a POC.