Shared components (multiple parents)
Hi,
I'm curious about the reason for the Component in AWT to have at most one parent. I can see that having multiple parents could cause problems when doing a layout for example, but I guess this reason belongs to the "bug preventing" category. There could be many situations where sharing a component could save quite a bit of resources.
Is there a real reason that prevents us from having shared components in AWT/Swing?
Message was edited by:
Cinnam
[485 byte] By [
Cinnama] at [2007-10-3 9:56:21]
How do you answer questions like:
component.getParent();
Swing is designed using MVC. So you share Models, not the View. For example
JTextField textField1 = new JTextField();
JTextField textField2 = new JTextField();
textField2.setDocument( textField1.getDocument() );
panel1.add(textField1);
panel2.add(textField2);
One problem with having multiple parents is with layout.
Suppose you are sharing a single component between two containers and it gets resized in one... should it then get resized in the other? If it does then this can create an infinite loop. If it doesn't, then painting your component in different places is going to be different because of the different dimensions.
I think we all see your point about wanting to share common data and a common way to render. The problem is that component is tightly tied into a third factor - it's actual dimensions and location. A few extra objects is normally worth avoiding this headache, but if you've really got a situation where you could save a large chunk of memory you should create your own custom solution
Thanks for replying.
> How do you answer questions like:
>
> component.getParent();
There could be a method
Container[] getParents()
Methods like isShowing() would still work, you could just "OR" the results from different parents etc.
> Swing is designed using MVC. So you share Models, not
> the View. For example
>
> JTextField textField1 = new JTextField();
> JTextField textField2 = new JTextField();
> textField2.setDocument( textField1.getDocument() );
>
> panel1.add(textField1);
> panel2.add(textField2);
Yes, but is the decision to forbid shared components based on the MVC pattern (to be 'true' to it), or is there something in AWT that wouldn't work if there were shared components?
Why I'm asking - I'm writing a simple GUI kit for mobile devices, which I base on the low-level API (the Canvas class) and I'm thinking whether or not I should forbid it too. Allowing multiple parents would make some things simpler, but perhaps there is something I don't realize at this moment, which could cause trouble in the future.
Thanks for the replies. If the layout problem is the only one, I think I'll give it a shot in my kit since I probably wouldn't need to react to the size changes. Layouting will be done rarely on the mobile, in most cases it will be called once (after the MIDlet starts).
> There could be a method
> Container[] getParents()
Thats not the question I asked. You just created a new method.
What if I want to get the parent frame of the component so I can close the frame based on some default action. (ie. I just clicked on the "Cancel" button)
> Thats not the question I asked. You just created a
> new method.
That's true. Sorry, I should have said it in the first post - I'm just looking for a reason which would prevent me from having multiple component parents in my own GUI toolkit. So far I've found only one thing (apart from the layouting, but that doesn't bother me too much), and that's checking if a component you are inserting into a container isn't that container's (not necessarily immediate) parent. This is more annoying with multiple parents, but still possible.
> What if I want to get the parent frame of the
> component so I can close the frame based on some
> default action. (ie. I just clicked on the "Cancel"
> button)
Well, you could do it for all of the parents in the array.
Regarding your question - perhaps in some situations it's necessary to know the component's one and only parent, but I don't see it at this moment.
> Regarding your question - perhaps in some situations it's necessary
> to know the component's one and only parent, but I don't see it at this moment.
I just gave you an example.
You have a "Cancel" button that you add to multiple non-modal dialogs that can all be open at the same time (different tool palettes for example). You write a generic ActionListener so then when the button is clicked, you close the dialog containing the button. So the generic code simply invokes the SwingUtilities.windowForComponent(...) to get the window so it can close the window. But it can't find the single parent because that relationship no longer exists.
So, basically using your approach you lose the ability to write generice code and classes of this nature.
I really don't understand what you are trying to do, because Swing won't allow you to do this anyway. Are you planning on rewritting Swing? Have fun.
> I just gave you an example.
>
> You have a "Cancel" button that you add to multiple
> non-modal dialogs that can all be open at the same
> time (different tool palettes for example). You write
> a generic ActionListener so then when the button is
> clicked, you close the dialog containing the button.
> So the generic code simply invokes the
> SwingUtilities.windowForComponent(...) to get the
> window so it can close the window. But it can't find
> the single parent because that relationship no longer
> exists.
Sorry, but I still don't understand what would stop multiparented version of Swing from invoking SwingUtilities.windowsForComponent(...) to get the array of windows so it can close every one of them. If I insert the same Cancel button into multiple dialogs, I have to know what I'm doing and be prepared for this behaviour.
> So, basically using your approach you lose the
> ability to write generice code and classes of this
> nature.
I can still have one parent, but I can also have multiple (and deal with the consequences, of course).
> I really don't understand what you are trying to do,
> because Swing won't allow you to do this anyway. Are
> you planning on rewritting Swing? Have fun.
No, that would be too much fun for me :) I'm just writing a simple GUI kit for mobiles, because the one in MIDP doesn't do much, and I was curious about this restriction.
Renderers/Editors are an example of shared components. For example JTable can display 10 x 10 cells each showing a clickable button, but instead of using 100 buttons it only has one button component, which acts as the renderer and editor.
To answer your question another way, java is platform independent and all platforms support a component heirarchy of single parents but not multiple parents. So java is just mirroring the underlying peer implementation (win32, etc).
