[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools] Re: editor extensions registration options?

Thomas,
Thanks for your response.
Good point about it being more than just a convention.
I could just try it in Eclipse, but I don't want to go down a path that
either 1) happens work today but will get broken down the road, or 2)
seems to work but causes non-obvious problems that I don't discover until
later.
- Gary

Thomas Mäder wrote:

> Gary,

> You might want to read §7.6 in the java language spec. I just have an old
> version handy, but in there it says that the host system may choose to
> consider it a compilation error if the public type in a compilation unit
isn't
> named like the compilation unit file itself. So it's not just convention. Why
> don't you just try it in Eclipse?

> Thomas

> Gary Johnston wrote:

> > We are building a graphical editor for a certain kind of "goober" (and
> > let's just leave it at that so that I don't have to spend space describing
> > what a "goober" is, which isn't really relevant).  A goober is actually
> > saved as a Java source file (i.e., a .java file and corresponding compiled
> > class file), one goober class definition per .java/.class file in our
> > case.  So, every goober shows up in the Navigator as a .java file, but not
> > all .java files are goobers, of course.  We'd like to register our goobers
> > (with the editor extension point) such that 1) goobers have a distinct
> > icon in the navigator (so user's can tell which .java files are goobers
> > and which aren't), 2) double-clicking on a goober source file opens our
> > goober editor (rather than the Java source editor), and 3) the file is
> > otherwise treated as a normal .java file (e.g., the Java source editor
> > could be opened on it via "Open with" from the context menu).
> >
> > The approach we're considering is to register (in our plugin.xml) the
> > extension "goober.java", specifying our own goober icon and our goober
> > editor.  I have a few questions about this approach:
> >
> > 1) Would this basically work the way we want it to?  Would our icon be
> > used by the Navigator for .goober.java files, or would it just be ignored
> > (i.e., .java file icon would override it)?  Would our editor be invoked if
> > one double-clicked on a .goober.java file, or would the Java source editor
> > still be invoked?  Would the Java source editor still be available via
> > "Open with" from the context menu?  More generally, does an "foo.bar"
> > editor extension registration override a "bar" extension registration
> > while still leaving "bar" registered tools available via the context menu,
> > etc.?
> >
> > 2) Are we making any trouble for ourselves WRT the Eclipse Java tools due
> > to the fact that our goober .java and .class files won't follow the common
> > convention that, for example, MyClass.java contains the definition for a
> > single class, MyClass, and compiles to MyClass.class?  Our approach
> > violates this convention because the class defined in, say,
> > MyGoober.goober.java would be MyGoober and would, of course, compile to
> > MyGoober .class.  This is perfectly valid Java, of course, and so
> > shouldn't be any problem for the Eclipse Java tools unless they assume the
> > convention is being followed.
> >
> > 3) Is there some other (better) approach we should take?
> >
> > Thanks for any help or advice.