The objects are loaded, however the Wicket UI uses the compile time type of the list to determine what columns to render.
I could imagine us allowing some sort of hint for the framework to be told to render the objects as per some other type (eg some "union interface" that combines all desired properties). But that would be a new feature, I think. Dan. On 23 Nov 2015 1:16 pm, "Vladimir Nišević" <[email protected]> wrote: > Hi, I have perhaps similar issue. > > I have an object (Order) which contains a list of objects can be different > type but all extend from the same superclass (Step). When I execute the > action on order thru wicket UI, the properties of concrete classes > StepType1 and StepType2 are not loaded. When I do the same thru > Intergration Test, the values are there? > > > *class Order{* > *.....* > *//region > steps (collection)* > *@Column(allowsNull = "true")* > *@Persistent(mappedBy = "order", defaultFetchGroup = "true")* > *private List<Step> steps = new ArrayList<>();* > > *@Collection(editing = Editing.DISABLED)* > *@CollectionLayout(render = RenderType.EAGERLY)* > *public List<Step> getSteps() {* > * return steps;* > *}* > > *public void setSteps(final List<Step> steps) {* > * this.steps = steps;* > *}* > *....* > *}* > > > *abstract class Step{* > *....* > *//region > order (property)* > *@Persistent(defaultFetchGroup = "true")* > *@Column(allowsNull = "false")* > *private Order order;* > > *@MemberOrder(name = "General", sequence = "1.1")* > *@PropertyLayout(named = "Order", hidden = Where.PARENTED_TABLES)* > *public Order getOrder() {* > * return order;* > *}* > > *public void setOrder(final Order order) {* > * this.order = order;* > *}* > *.....* > *}* > > > *class StepType1 extends Step{* > *//region > ipAdresse (property)* > *private String ipAdresse;* > > *@MemberOrder(sequence = "1")* > *@javax.jdo.annotations.Column(allowsNull = "true")* > *public String getIpAdresse() {* > * return ipAdresse;* > *}* > > *public void setIpAdresse(final String ipAdresse) {* > * this.ipAdresse = ipAdresse;* > *}* > *....* > *} * > > *class StepType2 extends Step{* > *....* > *private String dslam;* > > *@MemberOrder(name = "Output", sequence = "1.0")* > *@PropertyLayout(named = "DSLAM")* > *@javax.jdo.annotations.Column(allowsNull = "true")* > *public String getDslam() {* > * return dslam;* > *}* > > *public void setDslam(final String dslamId) {* > * this.dslam = dslamId;* > *}* > *.....* > *} * > > > > > 2015-11-22 15:23 GMT+01:00 Dan Haywood <[email protected]>: > > > On 21 November 2015 at 22:01, Stephen Cameron < > [email protected]> > > wrote: > > > > > Actually, it already does have the behaviour that I wanted. > > > > > > > > OK, that's good to hear. > > > > > > > > > > I'll try individual icons for the subtypes and see if it uses them > > instead > > > of the one for the base-type. > > > > > > It should do. In the todoapp we use the similar cssClass() to return a > > CSS class name per instance, and then use application.css to style the > > different values. This is how individual rows within a table show some > > todo items "crossed-off", ie with a line through the centre. The icons > > also vary on a case by case basis. > > > > Cheers > > Dan > > >
