Home » Language IDEs » Java Development Tools (JDT) » Extending JDT's CompilationUnitEditor to provide custom editor?
| Extending JDT's CompilationUnitEditor to provide custom editor? [message #243626] |
Thu, 10 May 2007 10:34  |
Eclipse User |
|
|
|
Originally posted by: hungyao.tjia.ca
Hi all,
I've googled extensively on this subject, but I can't seem to find an
authoritative answer anywhere - hence this posting :-) And it's already
been going on 3 or 4 days now...
Anyways, my current project involves trying to port a customized, internal
build process to Eclipse, as an Eclipse plugin. Part of the requirements
specify an actual editor for the source files. Now, although the source
files are Java, some of them use preprocessor directives and additionally,
there are special references to strings in a separate resource file for
i18n purposes:
i.e., we might go:
...
String asdf = "";
//#ifdef SOME_VARIABLE
asdf = Resources.getResource(SOME_RESOURCE_KEY);
//#else
asdf = "Default";
//#endif
...
where SOME_RESOURCE_KEY is subbed in at compile time by the compiler.
We've already defined a custom builder for this project (since obviously,
the Java Builder isn't going to compile such syntax) and this works fine.
Next step is to define a custom editor.
So, my question is, since our source files are _mostly_ valid Java source
with the exception of those two language features above, is it possible to
extend JDT's CompilationUnitEditor to not flag those as errors and
continue provide all the other features of the JDT's Java Editor like
on-the-fly syntax checking, highlighting, hover, etc...?
I understand there are some sticky issues with the presence of
preprocessor directives and the ability to refactor code as it is harder
to be syntax aware. However, we should be able to verify the existence of
a resource key by checking a specially marked up resource file.
Any suggestions or alternative methods would be welcomed! :-)
Andrew
|
|
|
| Re: Extending JDT's CompilationUnitEditor to provide custom editor? [message #243745 is a reply to message #243626] |
Tue, 15 May 2007 06:51  |
| Eclipse User |
|
|
|
Andrew Tjia wrote:
> Hi all,
>
> I've googled extensively on this subject, but I can't seem to find an
> authoritative answer anywhere - hence this posting :-) And it's
> already been going on 3 or 4 days now...
>
> Anyways, my current project involves trying to port a customized,
> internal build process to Eclipse, as an Eclipse plugin. Part of the
> requirements specify an actual editor for the source files. Now,
> although the source files are Java, some of them use preprocessor
> directives and additionally, there are special references to strings
> in a separate resource file for i18n purposes:
> i.e., we might go:
> ..
> String asdf = "";
> //#ifdef SOME_VARIABLE
> asdf = Resources.getResource(SOME_RESOURCE_KEY);
> //#else
> asdf = "Default";
> //#endif
> ..
>
> where SOME_RESOURCE_KEY is subbed in at compile time by the compiler.
>
> We've already defined a custom builder for this project (since
> obviously, the Java Builder isn't going to compile such syntax) and
> this works fine. Next step is to define a custom editor.
>
> So, my question is, since our source files are _mostly_ valid Java
> source with the exception of those two language features above, is it
> possible to extend JDT's CompilationUnitEditor to not flag those as
> errors
Did you disable the built-in Java compiler?
Dani
> and continue provide all the other features of the JDT's Java Editor
> like on-the-fly syntax checking, highlighting, hover, etc...?
>
> I understand there are some sticky issues with the presence of
> preprocessor directives and the ability to refactor code as it is
> harder to be syntax aware. However, we should be able to verify the
> existence of a resource key by checking a specially marked up resource
> file.
>
> Any suggestions or alternative methods would be welcomed! :-)
>
> Andrew
>
|
|
| | |
| Re: Extending JDT's CompilationUnitEditor to provide custom editor? [message #243820 is a reply to message #243765] |
Thu, 17 May 2007 11:17 |
| Eclipse User |
|
|
|
Originally posted by: hungyao.tjia.ca
Daniel Megert wrote:
> Andrew Tjia wrote:
>> Daniel Megert wrote:
>>
>>> Did you disable the built-in Java compiler?
>>
>>
>>> Dani
>>
>>
>> Yup, I've disabled the Java Builder.
>>
>> From what I understand, there are two ways that problems are reported
>> - by the build process, and by the on-the-fly syntax checker (enabled
>> via Preferences > Java > Editor > Report problems as you type).
>>
>> We would like to maintain the on-the-fly syntax checking though (the
>> process where the concrete syntax is converted into an AST, and
>> "resolved" by the Compiler class in the JDT) but extend it somehow to
>> understand this new syntax. We already have coded a custom builder
>> that will compile this syntax (something I didn't write)...
> This would be on the JDT Core (i.e. compiler) side and not in the editor
> itself.
> Dani
Ahh, I see... I'm looking at the Compiler code now, and noticed that if I
can get an ICompilationUnit, I can get the IType from it, and use it to
help type checking in NameLookup. However, the only way I can find to
create an ICompilationUnit is from an actual Java source file. (i.e., via
IPackageFragment.createCompilationUnit() or a similar one in JavaCore).
Even if it doesn't exist, it will be written out by this method. Is there
any way to get an ICompilationUnit without actually having an associated
java source file? I have the stuff I need in an AST
< http://mobius.inria.fr/eclipse-doc/org/eclipse/jdt/core/dom/ AST.html>. I
know I can accomplish this by writing the AST out to .java and
interpreting this, but I would like to avoid this step if possible (one
less file to synchronize and cleanup later!) :-)
Thanks,
Andrew
|
|
|
Goto Forum:
Current Time: Sat May 10 14:04:54 EDT 2025
Powered by FUDForum. Page generated in 0.04435 seconds |
Home