I'm afraid I don't understand what you mean by "services" or "inject enclosing component in me".
I suspect that you have a valid use case that you would like to address, and I'd really like to understand what it is. I think it would really help if you would do the following: - Explain exactly what it is you are trying to do in as few sentences as possible. - Describe how you have tried to apply existing Pivot constructs to solve the problem, including source code as needed. - Describe specifically what you think is lacking that is preventing you from applying your solution. Include proposed API additions or changes as appropriate. That way, we can probably come to a workable solution. Greg On Jun 13, 2010, at 3:19 PM, aappddeevv wrote: > Greg, > > On the 2nd issue about services in the component, I tried using the script > but failed after an hour. I could not get it to work and it was getting a > bit hard to see how this would be easy for clients. > > However, I found a better answer. Because of (PIVOT-513), the serializer can > use wtkx:define object's and insert the enclosing object into the newly > created object (e.g. because it has the interface > "InjectEnclosingComponentInMe" on it) all of which is non-pivot. > > The services can be placed into the user data directly after this processing > so it won't get gc'd. Its coding once, but the capability can be bundled > into a serializer class and re-used easily by clients. The only downside is > that a specific serializer has to be used but that's life under PIVOT-513. > > So component level services can be added to a component through this > mechanism, which works very nicely. It does require a protected method to be > created (to retrieve a serializer value) to get the enclosing object that > contains the wtkx:define - 3 lines. Even though the approach for #2 was > really small (about 5 lines to the Component class) this one is even smaller > and more general. There is a 3 line change in the serializer class but no > existing APIs are changed. > > I am still looking at #1 around defaulting across the tree. > > > > -----Original Message----- > From: aappddeevv [mailto:aappdde...@verizon.net] > Sent: Sunday, June 13, 2010 1:05 PM > To: dev@pivot.apache.org > Subject: RE: [jira] Updated: (PIVOT-514) > > BTW, I am trying to get item 2 below moved completely into script as you had > suggested. Running into problems when I need to attach the same behavior > object to 2-3 listeners to execute the needed behavior. I don't mind using > script. > > -----Original Message----- > From: aappddeevv [mailto:aappdde...@verizon.net] > Sent: Sunday, June 13, 2010 10:02 AM > To: dev@pivot.apache.org > Subject: RE: [jira] Updated: (PIVOT-514) > > Whew...emails like mine always come out when you are rushing to get on the > plane... > > Those are good thoughts on design intent. Its really a question of where > you force users to encounter this complexity. Where you force complexity > /flexibility to be dealt with (the boundary line) is based on how you think > the market responds to these choices and where you wish to lay claim to > differentiation. > > I thought about my email after I sent it and wondered where the changes > really needed to go. I spent a few minutes making some changes to the > Component class and was able to allow it to set style properties at any > parent object and have it flow appropriately to every component of a certain > type below it in the tree automatically--no changes to the serializer. It's > not production quality and requires more thought, but its illustrative. I > was of course fortunate that the pivot code base is good as it took longer > to write the email than it did to change the code. > > <Frame ...> > <userData org.apache.pivot.wtk.TreeView="{showEmptyBranchControls: false}" > org.apache.pivot.wtk.Border="{backgroundColor:null, padding:2}"/> > <content stuff here> > <MyTreeView ... /> <!-- Styles auto-applied here based on > the class type, but any key could work. In this example, all TreeViews will > have the same style automatically --> > </content stuff here> > </Frame> > > Of course, there are different ways I could set styles including > subclassing, setting the skin or repeating styling info. I have to subclass > for the data management part (no way around that a lot of times) but this > was easy and consistent with pivot syntax and keeps it out of my value-add > work around domain data. > > I also tested the Initializer (which I called ComponentExtensionLifecycle > after seeing another pivot class with a similar name) thing to the user data > and the proof point was that I was able to send EventBus messages from the > component class for selection classes per bushe's blog I saw somewhere all > as a service. Since it's a component service...add it if you want, > otherwise skip it by not adding it to your user data. I was able to extend > behavior through composition and its highly reusable by others. For managing > the selection coming from anywhere in my application, this is a good thing. > I did not do the menu idea because I am still having trouble with the menu > syntax. Without element-map, I had to add it in code but the idea is the > same. It needs more thinking but showed potential for extension through > composition and services. I was bit surprised it worked the first time but > it needs some more proof points. I'll add the menu thing next to determine > real reusability. > > It was not a lot of change to demonstrate the use cases all without script. > Getting the hierarchical resources right may require more thought of course > so you never have to change the basics infrastructure again the future. I > was wrong about the serializer needing changes except needing element-map > support. But Component had some minor changes. > > > -----Original Message----- > From: Greg Brown [mailto:gkbr...@mac.com] > Sent: Friday, June 11, 2010 5:08 PM > To: aappddeevv; dev@pivot.apache.org > Subject: Re: [jira] Updated: (PIVOT-514) > > This all sounds quite interesting, but may be a bit more than we want or > need WTKXSerializer to do. Using the existing implementation you can > delegate a lot of what you are proposing to Java or script. I'm extremely > wary of making WTKXSerializer more complex than it needs to be, especially > since we haven't run into a real use case for a lot of this stuff. It makes > it harder to maintain the code and harder for users to understand. > > > ----- Reply message ----- > From: "aappddeevv" <aappdde...@verizon.net> > Date: Fri, Jun 11, 2010 12:26 pm > Subject: [jira] Updated: (PIVOT-514) > To: <dev@pivot.apache.org> > > Yes, this is very cool. My collection comment on this issue was purely what > interface is used to detect a call to add(). Declarative programming is an > important option for pivot clients and more importantly, has great tooling > potential. > > Just thinking out loud...and typing fast... > > Related to maps, probably one good user XML extension for the serializer and > that has a lot of uses cases is to specify a map as elements versus > attributes. Also, through more annotation magic, the default key generator > can be specified. Many lookups occur using a class (name) as a lookup key or > the key is easily statically specified by the object or its static nature. > The "elements vs attributes" approach allows you to specify the object > instance inline because specifying an object class to be instantianted in an > attribute value is ambiguous unless you add more DSL (e.g. instead of a $ > for a reference lookup, a % for an object creation). > > This allows me to specify a bunch of objects without always having to use > attributes. The object can be defined and instantiated inline for the map > versus referenced elsewhere. There are 2-3 major use cases for this e.g. > automated menu population/configuration. And by establishing a very small > convention, allows a large number of declarative processing scenarios that > create new class behaviors without subclassing/coding. This is the true > power of the serializer/component as a container thinking and doesn't put > too much burden on the serializer (i.e. avoiding full DI-container semantics > which is a lot of work to create and is not needed here). > > However, this is not compelling enough yet to suggest unless other pivot > elements (those 2-3 uses cases) are also enabled. > > For example, as a small convention with support, if the serializer > automatically scans the user data and finds an object with an > interface/annotation called "Initializer", the interface is called. This > initialize can in turn scan the user data for a menu specification and > automatically add or substract a menu (also in the user data) from the main > menu when the component has focus (or whatever). By combining this with > Component's "name", I can specify the attach point as a menu URL. This is > Component-level services configured at the Component level and entirely > optional all without subclassing in my application---I just write services > that are reusable and use composition to create new behaviors. All of this > has minimal API impact (almost none) but does need a small amount of > pivot-library level support. Any Component can be a menu contributor. > > If we add cross-tree hierarchical user data lookup (minimal API impact) and > object initialization lifecycle event signaling (some API impact), you have > ingredients to create significant defaulting and user data management > behaviors. This would help with additional application-level, declarative > thematic and stylizing defaulting. By using JSON for style specifications, > which I think is clever, combined with a defaulting system that is > cross-tree, you have a nice set of customization capabilities that reduces > the experience level needed to create great looking applications, avoids > coding (subclassing or using code to configure), enables easier tooling and > can employ declarative configuration for those that like it. Conceptually, > this is at the heart of managing the boundary between coding and > configuration in a *balanced* way. > > So in this area (element map, small "initializer" interface, cross-tree user > data lookup, contract for object creation/initialization), plus a little > convention enables a lot of flexibility and to Dirk's point, doesn't box you > in. This is an unique, targeted fusion of WPF and eclipse e4 thinking that > could be possible in pivot. I don't know enough about Adobe and other > frameworks to say how they handle complexity and flexibility. > > > > -----Original Message----- > From: Greg Brown [mailto:gkbr...@mac.com] > Sent: Friday, June 11, 2010 9:14 AM > To: dev@pivot.apache.org > Subject: Re: [jira] Updated: (PIVOT-514) > > I should add that WTKXSerializer *does* actually know about maps (or, more > specifically, dictionaries). If your class exposes a read-only dictionary > property (e.g. Component#getUserData()), WTKXSerializer will properly > populate the dictionary based on markup. For example: > > <Window> > <userData foo="abc" bar="$def"/> > </Window> > > The serializer will effectively call getUserData().put("foo", "abc") and > getUserData().put("bar", def), where def is the value of the page-scoped > variable referred to by "def". This is what allows styles to be set using an > element vs. a JSON string, for example: > > <Label> > <styles color="#ff0000"/> > </Label> > > vs. > > <Label styles="{color:'#ff0000'}"> > > WTKXSerializer caters to sequences and dictionaries because those are the > structures employed by XML. An XML element is effectively both a sequence > (containing sub-elements and text nodes) and a dictionary (mapping string > attribute names to attribute values). Since sets aren't really used by XML, > there's no need for WTKXSerializ > >
