Setting dictionary properties via elements is what I meant by an element based map. I'll try it out. I was really looking for it on the user data dictionary so if its in there, then that's good and that meets my needs for getting data into the user data without only relying on attributes.
I'm not sure what the best approach is either for inheritance of styles either. I do know that some basic infrastructure allows a wide variety of approaches so you don't have to pick one yet. I've seen the CSS styling approach in e4 and I noticed that there is a lot of web-page thinking with scripting on a "page" in WTKX so the java world thinking is definitely there. Not against any of that as long as we can do something or at least its not really hard to do something on your own. I'll look at the pub/sub API. I just need something that is easy to use and can be easily used to get event data into unrelated components. With regard to menus, I looked at the tutorials and there is a lot of code in that. Just defining a menus then attaching handlers in WTKX or code is a bit intense. I'll keep plugging at it though. -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Sunday, June 13, 2010 7:30 PM To: dev@pivot.apache.org Subject: Re: [jira] Updated: (PIVOT-514) I have to admit that I'm struggling to understand your use case. To your point below, I realized after I sent my last email that WTKXSerializer was lacking support for setting dictionary properties via elements (see PIVOT-528). It also did not support setting attached properties via elements (PIVOT-529). Both of these are now resolved. Based on what you said below, I am guessing that you are trying to create some form of style inheritance. That is currently (and intentionally) not supported. We have toyed with the idea of adding something akin to CSS classes, but we haven't settled on the best approach yet. To be completely honest, this discussion is making me question the recent decision to support subclassing in WTKXSerializer. It almost seems like you would be better off dynamically generating WTKX on the server using whatever framework works best, then loading the dynamically generated WTKX in your Pivot app. Couple other notes: - While you can certainly use EventBus in a Pivot app, you may also want to take a look at Pivot's own pub/sub API. I don't think we actually have a tutorial section for this yet, but this test app provides a simple example: http://svn.apache.org/repos/asf/pivot/trunk/tests/src/org/apache/pivot/tests /ApplicationContextMessageTest.java - Pivot already supports automated, dynamic menu configuration. See the Menus tutorials: http://pivot.apache.org/tutorials/menus.html G On Jun 13, 2010, at 10:02 AM, aappddeevv wrote: > 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 >
