> 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). The builder approach I proposed is just using Java, thus it is statically typed. If we do not lose any flexibility or conciseness with statically typed language, it is better to remain in the statically typed language. BXML has the same trait, the loss of static type checking for GUI builder part(including JavaScript depending parts also). 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. This is what I'm doing now and very helpful for developing pure Java pivot codes. Also the generated builders sample code includes a ready to run main code, it is quite easy to see the actual GUI by running the sample from eclipse. I created this because of the lack of these things in pivot, without them, it would not be easy to use Pivot in pure Java style. Also as I developed for CRUD library, the more emphasis on generics and annotation will be interesting. I have not seen that type of approach in other web frameworks. This is in part related to the host language. If the host language does not support generics, it is not possible to use generics(of cause it may simulate this, but it will be complicated), so they often generates source codes. Such source codes generation may be considered as poor man's generics. Since Java has evolved to have generics and annotation, it allows to handle meta information, it opened up this new possibility. The main deficiency of code generation approach is that they does not rely on the same code line (library) after code is generated. So they create more source code which make it difficult to maintain and if code generator had bug, there is no way to fix bug already generated by fixing code generator. in the same token, if new features are added to generics library, all the code which use the generic library will have the new feature, while in generated codes, it is not possible. 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. > -- Cheers, calathus
