Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0 Build Identifier: M20080911-1700 I am developing a plugin which defines its own template variable messageID. This variable uses my own reslover MessageIDResolver thet extends TemplateVariableResolver. I override the protected String resolve(TemplateContext context) method and return the generated value containing consequent numbers. When I create a template using my variable ${messageID} I encounter tw different cases: If the temnplate has unambiguous name such as "asd" it gets expanded immediatley an evetything is fine. If the template has ambiguous name such as log and there are multiple suggestions the suggestion box opens so that I can choose the desired template ot method or whaterev. It seems that the resolve method I had overriden is called once before I have selected my template and then again after I select it. The result is that my messageID are somethiong like "id1", "id3", "id5",... rather than "id1", "id2", "id3" Reproducible: Always
Actually the first call of resolve is to generate the preview and the second call is to generate the code. Maybe you should keep the generated code for preview locally and to insert it in the code rather than to call resolve again, because in certain cases this causes an inconsistency between preview and what is inserted in the code.
This currently works as designed: we want to make sure that whenever a variable is actually used (be it in the preview or the code), it gets resolved to the latest. Good example is a a timestamp. We could offer separate path/API for preview resolving. This would also be handy for variables that prompt the user for input and which should not happen during preview.
"We could offer separate path/API for preview resolving." This sounds acceptable. If I can separate preview from actual code generation I would be able to generate a sample or stub or just know that the last generated ID was generated for the preview. Please update the comments to mark your progress.
>Please update the comments to mark your progress. There are currently no plans to work on this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
