| Best way to implement plugin for compound java files? [message #225592] |
Wed, 08 March 2006 09:52 |
Eclipse User |
|
|
|
Hi all,
I'm implementing a plugin that extracts multiple java files from a
single file and displays it in multiple editors (actually a
MultiPageEditorPart). In order to get all the Java goodies my editor
subclasses CompilationUnitEditor. (I know, I know...) Because some
portions of the java files are shared, I need to synchronize some edits
between editors.
My question: How should I go about implementing compound documents?
My first crack at it was to subclass IEditorInput, thinking that this
subclass would give each editor a partial view on the file. But it seems
to me that CompilationUnitEditor expects an IFileEditorInput for saving
and whatnot. At least, I can't yet get it to work with just an
IEditorInput-derived class.
Another approach might be to create derived .java resources from the
master compound document, and try to manage the compound document by
trapping all edits to the derived files. My editor currently can open
separate .java files in the workspace, but is it possible to synchronize
the editors, and filter the workspace so that the derived .java files
are not visible to the user or the compiler?
Or should I shoot for a new kind of document provider, one that stitches
together fragments from the original file? (Code folding doesn't exactly
do what I want since the fragments may appear in different orders in
different editors.) If I go this route, will I still be compatible with
JDT features such as code folding?
Thanks for the advice,
David
P.S. Should I be sending this question to the jdt-ui-dev mailing list?
|
|
|
Powered by
FUDForum. Page generated in 0.03080 seconds
Home