>> From a strictly client/server perspective, we're in pretty good shape >> already - web queries are server-agnostic, and can be used to talk to any >> HTTP-based web service. However, what is potentially more interesting here >> are the CRUD frameworks - for example, it would be really cool to create a >> Grails plugin that would produce site scaffolding in BXML rather than HTML. >> A relatively thin Pivot loader app could retrieve these files from the >> server and present them to the user. > > Groovy is dynamically typed language. Grails is implemented in Groovy, so > these builder approach is not statically typed(no error detection at > compilation time).
I suggested Groovy only because it has a well-known and well-supported model for building CRUD applications. It was certainly not meant to be at the exclusion of other options. > I think BXML is a digression from pure Java solution, if you plan to refocus > Pivot, it is better to support builder style fully. > (I means it is OK to support BXML, but more strong support for pure Java > solution is very important) > This means just dropping 'final' from a few classes in wtk, and providing > sample Java codes in a separate tutorial(sample) for pure Java developer > using the builder styles GUI construction so that users can easily copy and > pastes from it. Agreed on dropping the final modifier. If you are willing to volunteer the time to create such examples, that would be great. > I think dynamic language, XML became popular in part due to the Java > language restriction, but now there are reverse trend to eliminate XML by > annotation. > I feel BXML is in the similar situation. I understand that you prefer to work with a more statically typed approach. However, please understand that other developers may have a different perspective, and that there are valid use cases for both. I think that Pivot should fully support your builder pattern, and it should also continue support BXML. Let's focus on moving Pivot forward, not endlessly debating which approach is "better". G
