Re: bindgen release
> Have you done any more work with using Bindgen with Wicket? It looks > interesting to me. No, but coincidentally I got an email from Igor about bindgen a few days ago. He's been putting some work into a maven apt plugin and then submitting a hand full of bindgen bugs that I've fixed. Igor's current concern is that bindgen recursively generates bindings...e.g. if you have @Bindable FooPage with an Employee field/method that has a first name string, bindgen will generate FooPageBinding, EmployeeBinding, and StringBinding, allowing you to do: foo().employee().name() Which is cool. Except that it doesn't know when to stop, so you'll end up with `XxxBinding` classes for a lot of classes you probably won't ever actually use. So, Igor is thinking about how to trim this back. It hasn't been a problem on my non-wicket projects, but I get what he's saying. Earlier this evening I released bindgen 2.3 to the http://repo.joist.ws maven repo with a fix for one of Igor's bugs, so you can try that out. Please do let me know how it goes. Fair warning, the bindgen docs are light-to-non-existent, but since people are starting to express interest in it, I'll get some in to place. Thanks! - Stephen - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
bindgen release
Hi, I just released bindgen 2, a type-safe alternative to OGNL-like string expressions, that works particularly well in component-based frameworks like Wicket. It integrates with javac and/or Eclipse to do things like: Employee e = new Employee(); Form f = new Form(); f.add(new TextField(e.name()); f.add(new TextField(e.employer().name()); (Pseudo-code.) The Eclipse integration is such that, as soon as you change Employee getName() to getName2(), and hit save, the "e.name()" line will no longer compile, and you'll have to fix the expression to "e.name2()". Disclaimer: I haven't actually tried it in a Wicket project, but, from what I know of Wicket, it should work well for binding to objects without string-based property models or inner classes. My post is somewhat motivated by a side-comment Gavin King made on his blog [1] about using annotation processors (as bindgen does) for Wicket's databinding. If you'd like to check it out, the website is: http://joist.ws/bindgen.html (Technically I built bindgen for use in my own web/orm framework project, Joist, but bindgen itself is standalone and has no dependencies on the rest of Joist.) Any feedback is appreciated. Thanks, Stephen 1: http://blog.hibernate.org/Bloggers/Java6CompilerPluginsAndTypesafeCriteriaQueries#comment10340 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring and Wicket - is it worth it?
> Better than hard-coding a bunch of big switch statements. OO has a nice way of dealing with switch statements: polymorphism. If you know the environments up-front, you can define an interface and have each environment class implement it. Though, if you're defining environments on the fly, then, yeah, that becomes harder. Lack of abstraction is generally what plauges anything XML though--look at ant. - Stephen - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring and Wicket - is it worth it?
> I wasn't saying that's the only other way - just unfortunately the one > a lot choose. I'll give you that. :-) - Stephen - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
