On 14 August 2011 10:17, Roger and Beth Whitcomb <[email protected]> wrote: > 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.
Yes, I think Roger's proposal can be split into at least 2 distinct parts for discussion purposes. 1) Introduction of a common API across applicable Components to expose certain shared functionality. 2) How best to achieve 1) whilst considering architecture, code duplication, maintenance (of code and the API), flexibility etc I personally think part 1 is a valid and valuable suggestion , but it would probably benefit from a little further discussion on the mailing list to gauge consensus. Part 2 would certainly required both discussion and investigation (unless someone like Greg or Todd already have all of this in their heads from years of experience with Pivot) but that is perhaps premature until 1 is agreed upon. Although the original proposal comes with a specific example in the form of a TextOperator API, I don't think that needs to be the focus of the discussion right now. Assuming that there are no good reasons not to accept part 1 as a useful improvement, then the discussion can move on to the actual areas of functionality within Pivot that might benefit from such APIs. For instance, undo/redo might become a separate Undoable interface that a TextOperator interface extends. > 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.... If the focus is on identifying the common methods required to achieve cut/copy/paste across textual components, then I think it is appropriate that only the *required* methods be included. This is what my previous point (above) was alluding to. Perhaps a TextOperator interface would extend Clipboard, Undoable and *TextSelection*, or extend the first 2 and define the text selection methods relevant to this 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. >>>>>> >>>>>> >>>>>> >>>>> >> >> >> >> >
