pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: [jira] Updated: (PIVOT-514)
Date Sun, 13 Jun 2010 23:41:09 GMT
I'm afraid I don't understand what you mean by "services" or "inject enclosing component in

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.


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:aappddeevv@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:aappddeevv@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:gkbrown@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" <aappddeevv@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:gkbrown@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

View raw message