| suggestions to make the java editor extendable [message #201425] |
Wed, 20 April 2005 06:09 |
Eclipse User |
|
|
|
Dear jdt developers,
I need extra functionality in the java editor and rebuilding it is not
an option because one man cant accomplish what all of you did in the
past. So I have to get into the jdt.
Some things I need are colored preprocessor directives within //#
comments and an adaption of mark occurrences.
My current approch is to subclass CompilationUnitEditor and related
stuff to replace the singlelineCommentScanner and to fiddle in my
ocurrences marker. To get the whole jdt functionality I have to copy the
plugin.xml and this would be a maintenance nightmare. And I do not know
if this will work as expected and if _every_ functionality of jdt will
be available.
I wonder if the editor was never meant to be extentable (replaceable) or
if you, the developers, have not had the time to do so by suppling
extension points within the editor.
My suggestions to solve my problems from your side of the fence :-) are
the following:
1. Provide a full extension point mechanism with extendable scanners,
presentation reconcilers, partitions etc. This means major refactoring
of several classes. Every hardcoded field access must be removed and
replaced by dynamic structurs. Also a lot of classes must be unified
through proper superclasses so polymorphism can take control (e.g.
scanners are all instantiated differently at the moment).
2. Provide some setter and getter methods public and maybe some
initialize methods to replace objects and give them new functionality.
This is the least invasive and fastest to implement approch. The
interessting objects to get hands on are JavaSourceViewerConfiguration
and JavaTextTools. within the JavaSourceViewerConfiguration making the
scanners and maybe the reconcilers settable would help very much.
Encapsulating methods and classes regarding ocurrence marking and
pulling them out of the editor would increase readability of the
JavaEditor class.
Ether way it is important that within the jdt no instances are created
directly like the two classes mentioned above are throughout the code.
This would also ease your life because your code would be easier to
maintain if instantiation is done in one place.
Another problem IMHO is configuration of objects. Maybe initialsation
and configuration of objects should be refactored out to an interface.
This makes it possible to cleanly alter objects and restart them. The
semantics of configuration and initialisation (the information when an
object is ready) is clear cut and centralized in one point. It is also
unified and you have to learn only this interface to understand the
lifecircle of an object. At the moment, every class configures itself
through hardcoded methods, callers must literally know them to deal with
objects of this class and have to call them at the right time. The
programmer has to know all of them, too.
Having a small interface with configure(Configurator configurator) and
isConfigured() would replace all the small init methods throughout the
code. The Configurator would have a configure(Object objectToConfigure)
method and can alter its client the way it wants through setter methods.
This approch makes it easy to manage several configurations for an
object and replace them at runtime. Other plugins can change the jdt
classes in a clean way while preserving its other functionality.
I know I talked alot about internal stuff here and I dont want to tell
anybody how to do their job. But I really like to know where development
related communication takes place and where design issues are decided,
so I can read about the ideas behind the code and probably find another
way to do my job.
How is the development itself organized? Does every developer code
against the latest cvs version? Does everybody commit at will and the
others update regularly or is the commit step synchronize and monitored?
Dont be scared I will not try to comit my strange ideas :-)
My last questions are if any of you has the time and is willing to take
my suggestions into consideration? And would such changes be subject to
general bookkeeping or is it a minor change which gets patched in silently?
Regards,
Richard
PS
I am not alone with the problem of extenting the java editor as this
question comes up regularly. So providing some hook methods would
silence some noise on this newsgroup. The warning not to use internal
code remains untouched.
|
|
|
Powered by
FUDForum. Page generated in 0.13215 seconds
Home