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
