One of the ideas I have for WWB 2.0 is to allow Apache JXPath expressions for instead of straight bean properties. Also, you’ll be able to specify the same kind of expressions for parameter values. This makes all parameter values dynamic - unlike most of the parameters in WWB 1.x. JXPath functions can be implemented in Java. This would allow for a great deal of flexibility. For example, this would let you call a function for a parameter’s value and have some complex logic behind it.
Archived Comments
Daniel -
Will JXPath allow to use Java classes that don’t conform to Java Beans ? I’m trying to use WWB to build an interface for classes generated with XMLBeans from a XSD Schema, the main problem seems to be that the classes have no non-parameters constructor, but are created using Factories. Do you think WWB will be able to deal with that case in 2.0 ? Cheers, Daniel
Dan Syrstad -
I’m currently fleshing out the design, but the current plan is that a pluggable bean factory will be supported. Also, JXPath will be supported via a pluggable PropertyResolver interface. This will allow other types of expressions to be used, not just JXPath expressions.
Jurek -
I just discovered web beans. My compliments on your work. I was wondering if you had given any thought to non-Java enumeration in the new version. Is it possible that annotations could be used to implement custom/dynamic runtime enums? Otherwise it seems that requires a fair amount of work to get fields to work on existing beans. One either has to go back and refactor many of one’s existing classes or one must write a class that shadows the original (in my case) hibernate pojo. Thanks, Jurek
Dan Syrstad -
Jurek: Thank you for your comments. WWB 2.0 will be a departure from 1.x. It will be much more of a bean-binding and component composition framework. To your question, drop-downs will be bound to a current value from the bean and have a second binding to a list of possible values (possibly from another bean). NonJavaEnum has gone away in 2.0. In 1.x you don’t need to change your beans, you can implement new components and register them with ComponentRegistry. Your new component can know how to deal with your custom enum type. I do realize the limitations of 1.x and that’s what I’m trying to address in 2.0. But it should be understood that POJO does not necessarily mean Hibernate/persistent/domain object. WWB POJOs represent a model for the UI. Sometimes your UI model will not map directly to domain objects. Hence, you may need to write additional POJOs to complete the model. -Dan
Dan Syrstad -
You should work with the trunk (1.1). The wwb-2.0 branch is still experimental right now. I’m always happy to take in patches!
Nick H -
WWB looks interesting and I’d like to start extending it to meet some of my immediate needs. Which branch should I be hacking on? Do you want patches? Feel free to contact me by email for more info.
Martin Schlegel -
When will Wicket 1.4 be supported?
Dan Syrstad -
I’ll try to add support for Wicket 1.4 when it goes final. I’m really looking for someone interested in taking over the WWB 1.x code. I’m currently putting any time I have available (not much) into 2.0.
Martin Schlegel -
Maybe you could make a 1.4 branch. I’ve played a bit, to push wwb to wicket 1.4 but the DatePicker is making troubles. What about the DatePicker? It disappeared at wicket-stuff. How do I get commit rights?
vhik -
I would strongly suggest you take a look into Jaxen. It also allows for custom object models