The main purpose for my proposal wasn't to put these three classes
together, but rather to abstract some of the common functionality so
that this functionality could be manipulated in common for any of the
three types of fields. So, it is a little bit different than what it
sounds like you're envisioning.
My main concern with what I've proposed is that, although I need some of
the selection logic to work with Cut and Copy, the rest of the selection
stuff is not there, so it looks kind of disjointed. But, apart from
these methods, the rest of the selection logic has different signatures
and different implementations between the three classes, so that it
would take a bunch more time to bring them together into a common
interface....
On 8/13/11 2:27 PM, DreamTangerine wrote:
OK, I see your point of view and maybe you are right with
List/Table/Tree views (I need to think more about it), but in the case
of text components, here are my points :
* Three classes with the word "Text" that are also "Component", seem
like share a lot of functionality and need a common class.
* Also I am the developer of JMySpell
(http://kenai.com/projects/jmyspell) and some day I want to implement a
UI library for Pivot (may be when text components are more stables), so
in my little experience and IMHO both behaviors are needed at the same
time (Text and Component), text is needed to analyze/replace/anchor
positions/etc... but component behavior is also needed for
focus/visibility/destruction.
* In fact these a discussion about hierarchical implementations (aka
make inheritance only for implementations or delegate).
On sáb, 2011-08-13 at 11:21 +0700, Chris Bartlett wrote:
I imagine that Greg will have some strong opinions on this :)
I just tried writing a proper reply a couple of times, but couldn't
get the wording right. I'll try again once I have had some sleep if
the following is still not clear.
Without looking into this in any detail, my gut reaction is that just
having these classes implement a clearly defined interface (for each
common area of functionality such as text operations or selection
handling) would be preferable. Then a developer could create their
own compatible classes that implement the interface(s) without being
forced to extend a particular Pivot class.
Roger has identified a set of common text operations that are
conceptually the same, but the actual implementation of the methods
defined in the interfaces would not necessarily be the same across the
implementing classes. If the implementations are different, then
inheritance of the methods themselves doesn't add much value, as the
methods would have to be overridden. The main value comes from the
common API shared across the classes, and the ability to treat
TextInput, TextArea& TextPane the same for these text operations via
that API.
Chris
On 13 August 2011 07:35, Sandro Martini<[email protected]> wrote:
And probably even a base class for List/Table/Tree View classes ...
Il giorno 13/ago/2011 02:16, "DreamTangerine"<[email protected]>
ha scritto:
I think is better to create a common base class TextComponent where
TextInput, TextArea and TextPane are children.
And I think that maybe it is useful have also these methods setText
getText.
On vie, 2011-08-12 at 17:48 -0400, Roger L. Whitcomb wrote:
I'm implementing Cut/Copy/Paste, etc. in our UI and it is fairly awkward
to have to check for TextInput, TextArea and TextPane on every operation
and do the casts three times for each. So, I was wondering what
everyone thought of a "TextOperator" interface that these three classes
implement that consists of the relevant methods:
public void cut();
public void copy();
public void paste();
public void undo();
public void redo();
public void clearSelection();
public void selectAll();
public int getSelectedLength(); // Necessary for
determining enabling of cut/copy
public String getSelectedText();
This way I could cut my work to 1/3 because I simply have to cast to
"TextOperator" and do the operations (checking for "instanceof" also).
So, what does everyone think? It would be relatively trivial to
implement the change (add the interface file and add "implements..."
clause to the three classes (I think, not having prototyped it yet).
Roger Whitcomb
Architect, Engineering
Ingres Corporation
[email protected]<mailto:[email protected]>
PHONE +1 650.587.5596
FAX +1 650.587.5550
www.ingres.com<http://www.ingres.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
