| extending the Java Editor [message #200159] |
Mon, 04 April 2005 12:00  |
Eclipse User |
|
|
|
Hello,
I have to extend the Java Editor to handle directives like "//#def". My
questions are:
1.
Is the PresentationReconciler capable of several partitions?
org.eclipse.jface.text.presentation.PresentationReconciler.c reatePresentation(...)
seems to use only one partition and I do not know how to tell it to
handle my partition, too. I want my own partition with its own content
types. So far I registered a new PartitionScanner through a
IDocumentSetupParticipant and extended the PresentationReconciler with
another DefaultDamagerRepairer which will act on my own content types.
But the PresentationReconciler seems to use only one partition.
2.
There is a extension point org.eclipse.core.filebuffers.documentSetup
which uses IDocumentSetupParticipant to give plugins the chance to do
something with a document like setting up a partitioner. jdt seems not
to use this point, instead JavaDocumentSetupParticipant is instantiated
directly in ForwardingDocumentProvider. Why?
3.
Are the javaTextTools deprecated? The constructor of
JavaSourceViewerConfiguration implies it but why is the partitioner
still accessed through this object by JavaDocumentSetupParticipant?
I am sure, I simply dont understand how the flow of control is within
the jdt-ui but I have the feeling, that it is very complicated to extend
the java editor. There a lot of direct instantiations so you are often
forced to subclass. Interessting methods are either final or simply not
visible from the outside. And I do not see interessting setter methods
to simply set an object. Life (my life :) would be much easier if e.g.
JavaSourceViewerConfiguration had an setter for the
presentationReconciler or a list of AbstractJavaScanner objects so I can
add my own scanner easily.
Please correct my awfully incorrect view on programming in eclipse and
let me know if this is a flame which it should not be.
Regards,
Richard Nkrumah
|
|
|
|
| Re: extending the Java Editor [message #200314 is a reply to message #200237] |
Wed, 06 April 2005 06:40  |
| Eclipse User |
|
|
|
Hello,
Tom, thanks for aswering.
> Upfront - JavaEditor is internal, there is no support for extending
> it.
Yes, I am aware of this. Isnt it a pitty that a fundamental plugin in an
extendable platform isnt extendable itself? As my custom editor needs
also the full power of a Java IDE I cant craft my own jdt. Thats the
reason I bug everyone with silly details and hope that someday there
will be an api to extend the existing jdt instead of dupliacting everything.
>> 1. Is the PresentationReconciler capable of several partitions?
>> org.eclipse.jface.text.presentation.PresentationReconciler.c reatePresentation(...)
>> seems to use only one partition and I do not know how to tell it
>> to handle my partition, too. I want my own partition with its own
>> content types. So far I registered a new PartitionScanner through a
>> IDocumentSetupParticipant and extended the PresentationReconciler
>> with another DefaultDamagerRepairer which will act on my own
>> content types. But the PresentationReconciler seems to use only one
>> partition.
> PresentationReconciler has one damager/repairer pair per partition -
> you would need to modify the IDocumentPartitioner used to partition
> the document, adding your own custom partition. Then you could
> register a damager and repairer for that partition type.
But with this approch I would only extend the existing partition instead
of adding a new one. My biggest confusion comes from the use of the
terms partition and content type. In class PresentationReconciler
the method getPartition(IDocument document, int offset) uses the terms
in a strange way. It only calls TextUtilities.getPartition(document,
getDocumentPartitioning(), offset, false) which, bassicly, returns a
partition when you provide a partitioning as a parameter. So
you get what you give?! :) To me it seems that a IDocument(Extension3)
may have several paritions and each has its own IDocumentPartitioner.
Within a partition several content types may occurr. Am I right on this?
Also in the PresentationReconciler the method
setDocumentPartitioning(String partitioning) only sets _one_ partition
and only this one is queried in createPresentation(...) for content
types. Other partitions (like my new one) dont get a change to reconcile.
>> 2. There is a extension point
>> org.eclipse.core.filebuffers.documentSetup which uses
>> IDocumentSetupParticipant to give plugins the chance to do
>> something with a document like setting up a partitioner. jdt seems
>> not to use this point
> Not true - see the plugin.xml of org.eclipse.jdt.ui.
You are right. I didnt check the plugin.xml as I saw in
CompilationUnitDocumentProvider, that JavaDocumentSetupParticipant is
instantiated directly and passed to ForwardingDocumentProvider. So I
guess calling JavaDocumentSetupParticipant.setup(...) directly from
within ForwardingDocumentProvider is a left over from refactoring the
functionality into an extension...
>> 3. Are the javaTextTools deprecated?
> No. It would say so if it were.
For someone from the outside it is a little bit confusing that there are
several similar concepts like JavaTextTools and TextUtilities and that
the scanners are hosted by JavaSourceViewerConfiguration and the
partitioner by the JavaTextTools. JavaSourceViewerConfiguration
deprecates JavaTextTools in the constructor so there must be some
argument against the use of such objects.
>> Life (my life :) would be much easier if e.g.
>> JavaSourceViewerConfiguration had an setter for the
>> presentationReconciler or a list of AbstractJavaScanner objects so
>> I can add my own scanner easily.
> A source viewer configuration is not made to be customized - it just
> sets up the different strategies need by a source viewer. To
> customize it, you should copy or subclass.
I understand the approch but am I allowed to ask why this is so? The
whole system would be more dynamic if it would be possible to change
things on the fly instead of hardcoding everything. Whats bad about
telling an editor (SourceViewer internally) to use my object for
configuration if it conforms to some interface? Registering objects
which configure there clients makes it possible to manage configurations
and change configurable object at runtime.
I know all my questions are pointless because all you have to say is
that jdt is internal and everybody using it to develop own stuff is on
his own and has to live with the made design decisions. But besides that
I whould like to understand the guiding principles to design classes
which do not have a standard getter/setter mechanism and do not try to
instantiate objects in one place and registering them at other objects
instead of instantiating directly known classes.
Everybody feel free to ignore this criticism.
Richard
|
|
|
| Re: extending the Java Editor [message #200323 is a reply to message #200314] |
Wed, 06 April 2005 06:58 |
| Eclipse User |
|
|
|
Richard Nkrumah wrote:
>> PresentationReconciler has one damager/repairer pair per partition -
>> you would need to modify the IDocumentPartitioner used to partition
>> the document, adding your own custom partition. Then you could
>> register a damager and repairer for that partition type.
>
>
> But with this approch I would only extend the existing partition instead
> of adding a new one. My biggest confusion comes from the use of the
> terms partition and content type. In class PresentationReconciler
> the method getPartition(IDocument document, int offset) uses the terms
> in a strange way. It only calls TextUtilities.getPartition(document,
> getDocumentPartitioning(), offset, false) which, bassicly, returns a
> partition when you provide a partitioning as a parameter. So
> you get what you give?! :) To me it seems that a IDocument(Extension3)
> may have several paritions and each has its own IDocumentPartitioner.
> Within a partition several content types may occurr. Am I right on this?
> Also in the PresentationReconciler the method
> setDocumentPartitioning(String partitioning) only sets _one_ partition
> and only this one is queried in createPresentation(...) for content
> types. Other partitions (like my new one) dont get a change to reconcile.
Not getting into the other discussions, so just tackling this one: there
is an easily missable naming difference between 'partitioning' and
'partition'.
A _partition_ (noun) is a segment of a certain content type; a document
is partitioned into a sequence of partitions.
There may be more than one way to slice up (or partition, verb) a
document, e.g. you could imagine a JSP document being partitioned from
an HTML point of view or from a Java point of view. Both of these
_partitionings_ may slice up the document into multiple, but completely
different, partitions (e.g. TAG, ATTRIBUTE, TEXT for html, JAVA,
COMMENT, STRING for Java).
HTH, tom
|
|
|
Powered by
FUDForum. Page generated in 0.06562 seconds
Home