Actually, if you made a base class Content with three fields: String text, Image icon and Object userData, then both ButtonData and TreeNode could inherit from Content with nothing else added to either.... Also ListItem and TableViewHeaderData.
Roger Whitcomb | Architect, Engineering | [email protected] | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA +1 650-587-5596 | fax: +1 650-587-5550 -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Thursday, September 09, 2010 10:45 AM To: [email protected] Cc: [email protected] Subject: Re: Best practice for implementing Actions Quite possibly, though it isn't as critical for ButtonData, since you could easily create your own ButtonData subclass. This would have been more of a pain for the tree data, since you would have had to create two custom subclasses (one for TreeNode and another for TreeBranch). OTOH, it may not be a bad idea to add a user data property to all of the default content classes. On Sep 9, 2010, at 1:41 PM, Roger L. Whitcomb wrote: > Just wondering: you just added a "userData" member to TreeNode to help with context, would a "userData" member of ButtonData be appropriate/helpful here as well? > > Roger Whitcomb | Architect, Engineering | [email protected] | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA +1 650-587-5596 | fax: +1 650-587-5550 > > -----Original Message----- > From: Roger L. Whitcomb [mailto:[email protected]] > Sent: Thursday, September 09, 2010 10:38 AM > To: [email protected]; [email protected] > Subject: RE: Best practice for implementing Actions > > How did you do the "dependency injection" within the actions? I'm looking at my code, and I'm thinking along these lines too. Having the invoking component (esp. the MenuItem) helps for some things, but, as you say, often you need other kinds of context within the application, regardless of the UI context. > > Roger Whitcomb | Architect, Engineering | [email protected] | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA +1 650-587-5596 | fax: +1 650-587-5550 > > -----Original Message----- > From: Todd Volkert [mailto:[email protected]] > Sent: Thursday, September 09, 2010 10:33 AM > To: [email protected] > Cc: [email protected] > Subject: Re: Best practice for implementing Actions > > FWIW, I ran into this issue in one of my Pivot apps and took a > different approach altogether. Instead of looking at the context from > which the action was invoked, I looked at the state of the app in the > abstract sense. > > For instance, I might look at the selected path of a TreeView to see > which node they right-clicked on, or I might look at the selected item > of a list view cross-referenced with the selected items of a table > view. > > I my cases, I needed more than just how they were invoked. Very > specific to my case, I used dependency injection within the actions to > get the necessary state without hard-coupling it to the UI. > > This doesn't invalidate the thought that we might want to pass the > "invocation context" to the action's perform() method, but maybe it's > food for thought. > > Cheers, > -T > > On Thu, Sep 9, 2010 at 1:24 PM, Roger L. Whitcomb > <[email protected]> wrote: >> The Stock Tracker tutorial has it in 1.5.x also, I just left out the >> Tutorial code from my list. And yes, the Component is available in >> there as well. >> >> Let me think about how that works in what I have prototyped as well. I >> think that helps with the ugly case of having global variables that are >> referenced directly by class name. >> >> Roger Whitcomb | Architect, Engineering | [email protected] | >> Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | >> USA +1 650-587-5596 | fax: +1 650-587-5550 >> >> -----Original Message----- >> From: Greg Brown [mailto:[email protected]] >> Sent: Thursday, September 09, 2010 10:10 AM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: Best practice for implementing Actions >> >> Yes, that is exactly what I did. There is also some code in the Stock >> Tracker tutorial that calls perform() (it may only be in the 2.0 >> branch), but a Component argument also works there. >> >> On Sep 9, 2010, at 1:07 PM, Roger L. Whitcomb wrote: >> >>> So, looking for where the Action.perform() method is called from: >>> >>> - In Window.java from a key press - the context would have to >>> be the Window component >>> >>> - In Button.java - obviously the Button component (Menu.Item >>> and MenuBar.Item are both derived from this) >>> >>> That's all the places I can find - I guess that covers all the cases? >>> So, Component it should be. >>> >>> >>> >>> Roger Whitcomb | Architect, Engineering | [email protected]| >>> Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | >>> USA >>> >> <http://www.google.com/maps?f=q&hl=en&geocode=&q=500+Arguello+Street+%7C >>> >> +Suite+200+%7C+Redwood+City+%7C+CA+%7C+94063+%7C+USA+&sll=37.0625,-95.67 >>> 7068&sspn=50.557552,73.037109&ie=UTF8&t=h&z=16&iwloc=addr> | +1 >>> 650-587-5596 | fax: +1 650-587-5550 >>> >>> From: Greg Brown [mailto:[email protected]] >>> Sent: Thursday, September 09, 2010 9:55 AM >>> To: [email protected] >>> Cc: Pivot Dev >>> Subject: Re: Best practice for implementing Actions >>> >>> >>> >>> Ha. I think you have identified a valid issue with the Action >> interface: >>> the perform() method does not provide the implementor with any >>> information about the object that triggered the action. >>> >>> >>> >>> Now, this was originally by design - the thinking was that it should >> be >>> possible to execute an action regardless of the UI element that >> invoked >>> it. Since actions can potentially be triggered by multiple elements, >>> they should not generally have a dependency on a particular element. >>> However, that premise doesn't account for shared actions, or the >>> possibility that the developer may actually want to execute different >>> action behaviors based on the source value. >>> >>> >>> >>> In order to resolve this, I think we'll need to add an argument to the >>> perform() method that identifies the action's source. If we add it to >>> 1.5.2, it will be a breaking API change, which we generally try to >> avoid >>> in maintenance releases. However, I have already made one API change >> for >>> 1.5.2 (to the ResultList class, to resolve a serious performance >> issue), >>> so it is not out of the question. Since this is a major functional >>> limitation, it is probably worth doing. >>> >>> >>> >>> The only question in my mind is - what should the type of the source >>> argument be? It could be an Object, but I could also see an argument >> for >>> making it a Component (Action is defined in the org.apache.pivot.wtk >>> package, after all). >>> >>> >>> >>> Thoughts/comments? >>> >>> >>> >>> Greg >>> >>> >>> >>> On Sep 9, 2010, at 10:33 AM, Roger L. Whitcomb wrote: >>> >>> >>> >>> >>> >>> My application has a large tree in the left-hand side with context >> menus >>> (different) on every node of the tree. So, the context menu actions >> are >>> highly context-sensitive (the "Properties" item, obviously, would need >>> to know the exact selected object that the context menu was brought up >>> on in order to get the right Properties dialog). >>> >>> >>> >>> So, my question is: what is "best practice" as far as Pivot goes in >>> order to transmit this context into the Action.perform() method? The >>> "Expenses" tutorial seems to rely on global variables and using >>> "getSelectedRow" on that TableView object. So, is this the best way? >>> Is there some way I don't see to get the context directly in the >> Action >>> object? >>> >>> >>> >>> Thanks. >>> >>> >>> >>> Roger Whitcomb >>> >>> Architect, Engineering >>> >>> Ingres Corporation >>> >>> [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. >>> >>> >>> >>> >>> >> >>
