Ad 3: Like! Simple, no change to the build process necessary. If the generated PropertyModel doesn't carry the memory footprint of the runtime-generated bean subclass (mock) that's used for building it, I'm going to use it in my projects. (And otherwise I'll change that...)
Ad 1: The syntax looks really nice. The virality not. The build process neither. I don't really get why bindgen tries to limit that virality with cumbersome and refactor-unsafe property files. Why not add different types of annotations, or properties on annotations, e.g. something like @Bindable(includeUnboundMembers=false) to only process the annotated class itself, and only referenced classes that also have a @Bindable annotation? On Wed, Oct 10, 2012, at 19:42, Dan Retzlaff wrote: > I'd like to start a thread on Dominik Drzewiecki's suggestion of a > type-safe property model improvement for Wicket 7. I've seen a few > competing solutions: > > 1. Igor's metagen: https://github.com/42Lines/metagen > 2. Igor's bindgen-wicket: http://code.google.com/p/bindgen-wicket/ > 3. Carl-Eric's wicket-safemodel: > https://github.com/duesenklipper/wicket-safemodel > > We use our own metagen-like solution (written before Igor's) for use in > PropertyModels and JPA/Hibernate criteria queries, but we've been > eyeing... > 4. Querydsl (http://www.querydsl.com/) > > ... as a JPA/Hibernate query alternative. To avoid redundant Maven > plugins > and generated classes, I've been meaning to explore adapting Querydsl's > Q* > classes into a Wicket IModel. This approach is too heavy for a Wicket > "core" feature, but I mention it because on the surface it seems like the > cleanest option for JPA-backed Wicket projects. > > Is there a clear "best" here (or elsewhere)? Worst? :) > Igor, is it accurate to say that metagen supercedes bindgen-wicket? > Is it a reasonable goal for this to be a core feature, or does its > probable > Maven plugin relegate it to another (experimental?) module? > > Cheers, > Dan
