|
Re: adding custom JavaScript library to JSDT [message #529968 is a reply to message #528313] |
Tue, 27 April 2010 20:07 |
|
On 4/20/2010 3:08 AM, Philippe Marschall wrote:
> I was wondering what work would have to be done to add support for a
> custom JavaScript library to JSDT. I'm mostly looking for method
> proposals on global variables with documentation. Is there some
> documentation or examples?
Generally our libraries are either the actual .js files themselves or
non-functional "stubs" declaring the types and properties, in both cases
documented with JSDoc. Our system.js file, which is a stub for the
built-in types and properties of a JS runtime, can serve as an example.
It's provided by the plug-in as a reusable library, but getting your
..js file onto the project's Include Path any way you choose should yield
the same results.
--
Nitin Dahyabhai
Eclipse WTP Source Editing and JSDT
IBM Rational
_
Nitin Dahyabhai
Eclipse Web Tools Platform
|
|
|
|
Re: adding custom JavaScript library to JSDT [message #559147 is a reply to message #528313] |
Wed, 15 September 2010 18:50 |
|
Is there a way to add a library (directory of JS files and their associated JSDoc files) to the list shown in the "Add JavaScript Library" list... which currently includes ECMA 3, IE, and Firefox... along with "User Library".
I would like my library to be shown as a 'system' library, rather than a user library.
I would also like to be able to add this library to the Include Path programatically.
I just grabbed the source plugins for .support firefox & .support.ie... The answers should Lie Within.
UPDATE: Success! Cribbing from the IE & FF support plugins dramatically shortened my dev time, though I did make several changes. Both of the support plugins store things in char arrays rather than Strings because thats what the interface calls for. I had 22 file names, and really didn't feel like wearing my wrists out on a repetative task like that. I've got so many other things to wear them out on instead...
// what's plural of "chars"?
private static char[][] stringsToCharses(String strs[]) {
char [][]charses = new char[strs.length][];
for (int i = 0; i < strs.length; ++i) {
charses[i] = strs[i].toCharArray();
}
return charses;
}
private static final LIB_STRS[] = { "fileA.js", "fileB.js", ... };
privaet static final LIB_CHARSES = stringsToCharses(LIB_STRS);
public char[][] getLibraryFileNames() {
return LibInitializer.LIB_CHARSES;
}
Plus "fileA.js" is much easier to read (and debug) than the equivalent char array. Yow. It'd be easy to miss a dropped character buried in all those commas and quotes.
PS: I suggest overriding getWorkingLibPath in your LibraryLocation implementation. If you don't, you'll end up sharing the same "libraries" directory in the JSDT core plugin... which opens up the possibility of file collisions (with the most recent time stamp winning).
--Mark Storer
Senior Software Engineer
Autonomy Cardiff
import legalese.disclaimer;
Disclaimer<Cardiff> disCard = null;
Google Code Search
[Updated on: Fri, 17 September 2010 00:06] Report message to a moderator
|
|
|
Re: adding custom JavaScript library to JSDT [message #559756 is a reply to message #528313] |
Fri, 17 September 2010 21:59 |
|
Final update. More success!
To programmatically add a JS library to a project:
private void addJSLibToProj(IProject proj) {
IJavaScriptProject jsProj = JavaScriptCore.create(proj);
try {
IIncludePathEntry entries[] = jsProj.getRawIncludepath();
// an impl of IJsGlobalScopeContainerInitializer
LibInitializer jsLib = new LibInitializer();
// LibInitializer.getPath actually returns the LibraryID defined in the plugin.xml
// wrapped in a Path object. Funky, but okay.
IPath ourLibPath = jsLib.getPath();
IIncludePathEntry ourEntry = JavaScriptCore.newContainerEntry(ourLibPath);
IIncludePathEntry newEntries[] = new IIncludePathEntry[entries.length + 1];
System.arraycopy(entries, 0, newEntries, 0, entries.length);
newEntries[entries.length]= ourEntry;
jsProj.setRawIncludepath(newEntries, true, null);
} catch (JavaScriptModelException e) {
LogError( e );
}
}
Important bits to note:
1) we don't add it as a CPE_LIBRARY (from one of the JavaScriptCore.newLibraryEntry(...) overrides), but a CPE_CONTAINER. A CPE_LIBRARY appears to be a single file, while a CPE_CONTAINER can be any number of other Includable Things. Libraries in this case.
2) The "path" to that container is the library ID from the plugin.xml... as used in the org.eclipse.wst.jsdt.core.JsGlobalScopeContainerInitializer extension point (and ...UIInitializer).
It would be nice to have an "addLibraryByID" in IJavaScriptProject, but that would probably be too useful. Given the way "PROVISIONAL API" warnings are splashed all over everything, it'd be comforting to have that extra layer of insulation. Ah well... they don't call it "the bleeding edge" for nothing.
Not making IPath's out of things that are clearly not paths might be a good idea as well. Maybe just a subclass that makes it clear what's Actually Going On?
--Mark Storer
Senior Software Engineer
Autonomy Cardiff
import legalese.disclaimer;
Disclaimer<Cardiff> disCard = null;
Google Code Search
[Updated on: Fri, 17 September 2010 22:03] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.02484 seconds