This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 42646

Summary: [2004-05-05]Create non-cloneable multiview component
Product: platform Reporter: Milos Kleint <mkleint>
Component: Window SystemAssignee: apireviews <apireviews>
Status: CLOSED FIXED    
Severity: blocker Keywords: API, API_REVIEW_FAST
Priority: P2    
Version: 4.x   
Hardware: PC   
OS: All   
Issue Type: TASK Exception Reporter:
Bug Depends on:    
Bug Blocks: 41085    
Attachments: API diff
total diff for openide and core
new api diff
new complete changes diff.

Description Milos Kleint 2004-04-30 13:43:45 UTC
separate issue from #42451, will require changes
in multiview API and possibly openide.

http://openide.netbeans.org/tutorial/reviews/opinions_41085.html#tcr-life

Factory method to create plain TopComponent
Comment 1 Milos Kleint 2004-04-30 15:06:20 UTC
Created attachment 14643 [details]
API diff
Comment 2 Milos Kleint 2004-04-30 15:06:49 UTC
Created attachment 14644 [details]
total diff for openide and core
Comment 3 Milos Kleint 2004-04-30 15:17:19 UTC
I would like to introduce a new interface to TopComponent,
TopComponent.Cloneable2 which will allow instance based decision about
cloneability. This is required because of the multiview topcomponent
implementation. That one delegates to the inner elements for most of
the functionality. It needs to extend CloneableTopComponent, among
other things because if any of the inner elements is an editor, it
requires the multiview tc to be a CloneableEditorSupport.Pane instance. 
Without this change I would not be able to  either create a
non-cloneable multiview component or embed an editor view into the
non-cloneable multiview component. None of the options is satisfactory.

Existing TopComponent.Cloneable instances are untouched by this change.
Please see attached diffs (coming with suggested apichanges.xml diff
as well)
Comment 4 Jaroslav Tulach 2004-05-02 19:10:17 UTC
I have to admit that TopComponent.Cloneable mixes API and SPI and that
may be the root source of the problem. If TC.C was SPI, I would
support your suggestion to create TC.C2, but as it is also API, I am
going to object. 

If I understand correctly, there is one module (core/multiview) that
needs to implement contract of TopComponent and CloneableTopComponent
and instead of implementing those contracts twice it is going to enjoy
the power of the owner of the whole interface and simplify its work by
introducing new interface Cloneable2. 

This has a direct effect for everyone who is dealing directly with
TopComponent.Cloneable or CloneableTopComponent. I wish the multiview
team found another way around this issue. I believe this is not the
right way to go, as a first step I am removing the fasttrack keyword
and turning this into real review. I hope the core/multiview team will
find appropriate way how to solve the cloneability and will close this
request themselves.
Comment 5 Jesse Glick 2004-05-02 19:16:47 UTC
TC.C is not much of an API - its only likely client is the window
system impl. IMHO it is almost entirely SPI.
Comment 6 Milos Kleint 2004-05-02 20:32:03 UTC
I agree with Jesse, It's more SPI than API. 
What are the other possible clients wanting to clone arbitrary
TopComponent? 

Comment 7 Jaroslav Tulach 2004-05-03 15:36:43 UTC
I have to admit that I am not aware of any caller of the interface
outside of windows system. But adding new interface just for
communication between core/windows and core/multiview seems to me
overkill. Especially when the interface suggests that the lifecycle of
the component could change - e.g. for a while it could be cloneable,
for a while not. 

I really vote for much simpler solution: methods in MultiViewFactory
TopComponent createMultiComponent (...);
CloneableTopComponent createCloneableMultiComponent
and possibly, if needed
CloneableEditorSupport.Pane createMultiEditorPane (...);

If we find out that we need the new interface we can always add it
later, but it is not necessary to "chodit s kanonem na vrabce".
Comment 8 Milos Kleint 2004-05-04 06:37:40 UTC
the cloneability shall not change during the lifecycle of the
component. if the name suggests that, we might change the name to a
more obvious one.

your suggestion looks ok, 2 drawbacks though:
1. code duplication as I will havbe to facricate 2 exactly same
classes, each extending a different component (TopComponent or
CloneableTopComponent).
2. and more importantly: the non-cloneable multiview component could
not embed any editors. It's because the multiview component has to
implement CLoneableEditorSupport.Pane interface. 
Comment 9 Milos Kleint 2004-05-04 10:00:11 UTC
Created attachment 14682 [details]
new api diff
Comment 10 Milos Kleint 2004-05-04 10:00:40 UTC
Created attachment 14683 [details]
new complete changes diff.
Comment 11 Milos Kleint 2004-05-04 10:04:20 UTC
changes according to yarda's comments attached.
factory now has the createCloneableMultiView() methods that mirror
functionality of createMultiView()

limitations expressed earlier apply.
Comment 12 Jaroslav Tulach 2004-05-04 10:21:49 UTC
If the api changes are just in MultiViewFactory look like:

public static TopComponent createMultiView
public static CloneableTopComponent createCloneableMultiView

I am fine with the change.
Comment 13 Milos Kleint 2004-05-12 06:30:05 UTC
done as suggested
Comment 14 Jaroslav Tulach 2004-05-12 09:19:32 UTC
Unresolved issues resolved. Making fasttrack again.