Hi Chris, That's an extensive proposal. You have obviously put a lot of thought into it. I'd have some concerns about the complexity and overall approach, though. I have tried to capture these in my comments below.
> Example 1 - User defined, simplified API for creating object graphs > > <!-- 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. > 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. > Even just the ability to refer to a Component by a different name can > be very useful, especially when there are similarly named widgets in > various UI frameworks. I agree that this would be handy. But I'd prefer to see it implemented as a Java language extension (i.e. typedefs for Java). Among other things, it would help simplify the use of generics, and would also help maintain backwards compatibility (when a class is moved or renamed, for example). > 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. > ...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? > * 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. > 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. 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. G
