Greg, My replies are inline. You mention concerns, but do you see any value in i? Whether in my examples or in other areas?
The fact that it is a small, backwardly compatible change (unless I have missed something major) which offers many new possibilities and alternatives is the big selling point for me. Because it is such a small change, and limited to BXMLSerializer, it would be easy to just push this into a tiny Apache Extras project as Sandro suggested. I intend to put my proof of concept code up there in the next 48 hours anyway. Chris On 5 July 2011 20:29, Greg Brown <[email protected]> wrote: > That's an extensive proposal. Well, an extensive email, but a very simple proposal IMHO. >> <!-- This would create and populate a layout without needing to know >> how it was being implemented behind the scenes --> >> <ThreeColumnLayout> >> <leftColumn> >> ... >> </leftColumn> >> <middleColumn> >> ... >> </middleColumn> >> <rightColumn> >> ... >> </rightColumn> >> </ThreeColumnLayout> > > Why not simply create a new component named ThreeColumnLayout that defines > "leftColumn", "middleColumn", and "rightColumn" properties? It could either > extend TablePane or use it internally in its skin. I would argue that creating a new Component and/or skin would take longer, require more Pivot experience and quite possibly require more testing. With such a simple interface, even novice users would be able to use this to create very lightweight, standalone, aliases to meet their specific needs. If I know how to create an object graph in BXML (or in Java, obviously), I can very quickly produce an 'alias' for it. I very quickly (5 mins) implemented the workaround for this issue into a functioning 'alias'. https://issues.apache.org/jira/browse/PIVOT-768 Ultimately though, it is also about choice and flexibility. This is an alternative that might well be preferable to some people, much like using BXML might be preferable to constructing object graphs in Java. >> This is the original problem that lead to the proposed idea. >> Being able to create simplified APIs for Pivot Components means that >> designers could be provided with a much smaller and simpler 'toolkit' >> to work with. Having a smaller API would also be helpful for people >> who add in auto-complete functionality into their editor tools. > > Since all BXML properties are ultimately Bean properties, it should be > possible to implement auto-complete via reflection. In this case, it > shouldn't matter how many properties a component exposes. I was thinking more about manually adding 'templates' here for the auto-complete part, but that would be just as valid for a standard Pivot Component. The main point was that I can create my own custom subset of lightweight aliases that include only the properties or styles that I need or use. This could prove very useful for instance when a new member joins a team working on a Pivot app. They would instantly be able to see what is relevant for a certain scenario, merely because the alias would only perform tasks that *were* relevant to its purpose. >> The interface would have a single method named 'transform()' which >> would return a java.util.Collection<T>. > > This would be inconsistent with the rest of the Pivot API, which uses > org.apache.pivot.collections. Of course this could easily be switched to org.apache.pivot.* I was thinking more in terms of how such a feature might be used, and not wishing to impose the use of Pivot collections in a situation where they wouldn't add any value. ie Just a simple, short lived, bag of items that would be returned and processed almost immediately within the same class. >> ...If the original bean was going to be set as the value for a >> writeable property, each of the items in the Collection would be set >> as values for the same writeable property, in the order defined by the >> Collection's iterator) > > What would be the point of this? Why not just set the last one, since all of > the previous values would be overwritten? I was trying to explain the concept clearly, and not muddy the waters by including optimizations (obvious or otherwise). It also demonstrates that the change can be very unintrusive within the BXMLSerializer code. >> * What difference would that make? >> This simple change would provide flexibility by allowing a special >> type of 'Class Instance' (an implementation of Transformable) to >> decide how many items to return (and of what types) when it is >> 'created', rather than exactly 1 object as currently happens. > > The Serializer interface is designed to read and write a single object. If > you need to read or write more values, you can just use a collection as your > root object. Yes, and that is part of the point. It is currently 1:1, but perhaps there are valid use cases for 1:0, 1:1 & 1:n. For example the 'conditional include' example I gave can choose to return 0 items, and a 'repeater' class could clone or create a chunk of a GUI and repeat it n times. >> TablePaneBuilder implements Transformable<TablePane> and has 'columns' >> and 'components' properties. The latter being a Sequence<Component> >> annotated as the DefaultProperty. Its 'transform()' method returns a >> newly created TablePane with the requested number of columns, and >> sufficient rows to populate the cells using the supplied Components. > > The idea of supporting builders in BXML is not unreasonable. But I suspect > that there are probably simpler ways to accomplish it. Yes, there may well be *other* ways to accomplish this, but is this way particularly offensive? :) And is the provided TablePaneBuilder example not simple? > FWIW, you mentioned Lombok later on in the thread. We had been using Lombok > extensively on my current project but ultimately abandoned it because it made > using an IDE more difficult. Since the properties are generated via > annotation, the IDE can't see them and displays compiler errors in every file > that refers to them. Um, the Lombok properties/methods show up fine in Eclipse for me. I can't remember the current state of affairs, but think it supports at least one other IDE too, NetBeans perhaps? While I have had occasional compilation issues, they have been limited to deep object hierarchies, or large objects. I tend to use it while prototyping and then 'delombok' once things are more settled. Chris > > G > >
