I'm trying to build Dojo support into the sse/jsdt provided html/jsp/js
editors (i.e. i don't want to create some new version of these editors
like aptana has). I've been able to get something which approaches what
I want by using the org.eclipse.wst.xml.core.modelQueryExtensions
extension point for html element and attribute content assist, and using
the org.eclipse.wst.jsdt.ui.javaCompletionProposalComputer extension
point for javascript content assist within the javascript editor.

However I cannot seem to find an appropriate way to get my content
assist into a javascript code block within the html editor. I would
think that my org.eclipse.wst.jsdt.ui.javaCompletionProposalComputer
extension would also be applied to that partition of the html editor,
but it doesn't seem to work that way.

Is there any way to do this (other than what I've already tried below)?

I have tried:

1) adding a dojo installation to the build path -- isn't sufficient as
the parser won't pick up anything remotely resembling the level of
content assist that i require

2) providing a custom .js library and using the
org.eclipse.wst.jsdt.core.JsGlobalScopeContainerInitializer /
org.eclipse.wst.jsdt.ui.JsGlobalScopeContainerPage extension points --
content assist shows up, but it takes 20-30 seconds for the content
assist popup to appear (which doesn't appear to be a problem with my .js
file as the same delay can be seen using the internet explorer library).

3) inferencing engine extension (researched but not implemented as i
read some posts in another thread where someone implemented this
extension for dojo and also experienced 20-30 second delays).

(This is an example taken from org.eclipse.wst.jsdt.web.support.jsp/plugin.xml)

But as soon as Bug 258999 you will have much more control over where your content assist suggestions are activated and even would allow you to put them on their own page.

I hope that answers your question.

Blue Skies,

~Ian

Ian Tewksbury
WTP JavaScript Tools
IBM Rational
-----“When once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been, and there you will always long to return.” ~Leonardo da Vinci

I'm curious however, both the solution that you mention and the
org.eclipse.wst.xml.core.modelQueryExtensions solution I'm already using
both seem to "hijack" the content assist completely. Meaning in this
case, for example, if i want the existing javascript completions to show
up, I either have to extend JSDTContentAssistant or recreate the logic
in that class in some fashion.

If the above is correct then other plugins which also implement these
extensions won't play nice with one another. Will the "proposal cycle"
bugfix you mention in your previous post alleviate this issue? Or am I
missing the mark completely? I can successfully create multiple
extensions for the XML editor, perhaps the others support it as well and
I'm doing something incorrectly?

Originally posted by: adataylo.cisco.com
I'm curious however, both the solution that you mention and the
org.eclipse.wst.xml.core.modelQueryExtensions solution I'm already using
both seem to "hijack" the content assist completely. Meaning in this
case, for example, if i want the existing javascript completions to show
up, I either have to extend JSDTContentAssistant or recreate the logic
in that class in some fashion.

That is strange because in neither case should it be clobbering the results of the other processors. In the case of the provisional content assist extension all processors registered for a given partition type should be asked for their results and have them displayed. And in the case of the model query extension all of the model query extensions should be asked for their results. Though in this case it seems that the use of the provisional content assist extension is the more correct thing to do. But again it should just be adding its results to the other extensions, not clobbering them.

Something you may try is create two provisonal extensions of your own and register them for the same partition type and see if the results of both show up.

Another approach is, it sounds like you may have the WTP code in question loaded in your workspace and if you do you could take a look at StructuredContentAssistnat#getContentAssistProcessor which is the method that loads the provisional content assist extensions.

You are also more then welcome to open a Bugzilla against Source Editor if you are still having issues with the other provisional extensions getting clobbered.

Eclipse User wrote on Wed, 20 January 2010 22:59

Originally posted by: adataylo.cisco.com
If the above is correct then other plugins which also implement these
extensions won't play nice with one another. Will the "proposal cycle"
bugfix you mention in your previous post alleviate this issue? Or am I
missing the mark completely? I can successfully create multiple
extensions for the XML editor, perhaps the others support it as well and
I'm doing something incorrectly?

The fix for Bug 258999 definitely has no issue with multiple content assist computers (terminology change for the patch) registered for the same content type and region either displaying on their own content assist page or being appended to existing content assist pages for that region.

Also just so you know the fix for Bug 258999 while providing a much more configurable way of implementing content assist extensions will still load the what will become depreciated provisional content assist extension that is currently in place so if you write something using the current extension mechanism now it should continue to work after the enhancement.

Ian Tewksbury
WTP JavaScript Tools
IBM Rational
-----“When once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been, and there you will always long to return.” ~Leonardo da Vinci

On 1/21/2010 6:40 AM, Ian Tewksbury wrote:
> Eclipse User wrote on Wed, 20 January 2010 22:59
>> Originally posted by: adataylo.cisco.com
>> It appears that this works.
>
> I'm glad.
>
> Eclipse User wrote on Wed, 20 January 2010 22:59
>> Originally posted by: adataylo.cisco.com
>> I'm curious however, both the solution that you mention and the
>> org.eclipse.wst.xml.core.modelQueryExtensions solution I'm already
>> using both seem to "hijack" the content assist completely. Meaning in
>> this case, for example, if i want the existing javascript completions
>> to show up, I either have to extend JSDTContentAssistant or recreate
>> the logic in that class in some fashion.
>
> That is strange because in neither case should it be clobbering the
> results of the other processors. In the case of the provisional content
> assist extension all processors registered for a given partition type
> should be asked for their results and have them displayed. And in the
> case of the model query extension all of the model query extensions
> should be asked for their results. Though in this case it seems that the
> use of the provisional content assist extension is the more correct
> thing to do. But again it should just be adding its results to the other
> extensions, not clobbering them.
>
> Something you may try is create two provisonal extensions of your own
> and register them for the same partition type and see if the results of
> both show up.

I was mistaken. Sure enough when i code up 2 plugins as you suggest the
content assist from both plugins shows up (for both modelQueryExtensions
and contentassistprocessor). I did, however, discover what led me to
this false conclusion for javascript. I was testing on a project that
did not have the JS nature, and an NPE will be thrown:

when invoking content assist from within the script block of an html or
jsp file. Add the JS nature to the project, and voila the NPE goes away
and the JS completions show up.

I'm currently searching bugzilla to see if this is a known issue. In
the meantime I'll code to the contentassistprocessor extension.

Thanks!
Adam

>
> Another approach is, it sounds like you may have the WTP code in
> question loaded in your workspace and if you do you could take a look at
> StructuredContentAssistnat#getContentAssistProcessor which is the method
> that loads the provisional content assist extensions.
>
> You are also more then welcome to open a Bugzilla against Source Editor
> if you are still having issues with the other provisional extensions
> getting clobbered.
>
> Eclipse User wrote on Wed, 20 January 2010 22:59
>> Originally posted by: adataylo.cisco.com
>> If the above is correct then other plugins which also implement these
>> extensions won't play nice with one another. Will the "proposal cycle"
>> bugfix you mention in your previous post alleviate this issue? Or am I
>> missing the mark completely? I can successfully create multiple
>> extensions for the XML editor, perhaps the others support it as well
>> and I'm doing something incorrectly?
>
> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=258999
> definitely has no issue with multiple content assist computers
> (terminology change for the patch) registered for the same content type
> and region either displaying on their own content assist page or being
> appended to existing content assist pages for that region.
> Also just so you know the fix for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=258999 while providing a
> much more configurable way of implementing content assist extensions
> will still load the what will become depreciated provisional content
> assist extension that is currently in place so if you write something
> using the current extension mechanism now it should continue to work
> after the enhancement.

Originally posted by: adataylo.cisco.com
I'm currently searching bugzilla to see if this is a known issue. In
the meantime I'll code to the contentassistprocessor extension.

If you could please report back here with either an existing bug you found or the new bug you open, for documentations sake, that would be much appreciated.

Thanks,

~Ian

Ian Tewksbury
WTP JavaScript Tools
IBM Rational
-----“When once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been, and there you will always long to return.” ~Leonardo da Vinci