Are there differences in behaviour?

7 views
Skip to first unread message

Mario Giammarco

unread,
Jan 19, 2018, 10:16:25 AM1/19/18
to invesdwin-platform
Hello,
Imagine this situation:

- class Foo with FooPage
- class Bar

In Foo I have public Bar getBar() {...}

What does it change in rendering if Foo has a FooPage?

Thanks,
Mario

Edwin Stang

unread,
Jan 19, 2018, 10:25:17 AM1/19/18
to invesdwin-platform
Hi Mario,

- If you have a FooPage, the html generator will generate a FooPage.html with wicket:child as the tag under body.
- If you have a FooPanel, the html generator will generate a FooPanel.html with wicket:panel as the tag under body.

You can also have both and the html generator should work for both individually, rendering the same stuff internally. Though the rendering is also dependent on the new GeneratedBinding(this)... which could have some binding interceptors. Or some other component modifications you implement in the Page/Panel class individually.

Since you have public Bar getBar() {}, then in both cases Bar will be treated as a container type and thus its nested properties will be generated individually into the FooPage.html and FooPanel.html.
This does not care what you do with Bar itself, since it can also have a BarPage, BarPanel. If you want to render Bar as a Panel instead of a nested container type inside Foo. Then use:
@BeanPathEndPoint
public Bar getBar() {}
And additionally define a binding generator interceptor to instantiate the panel instead of the default text field as the desired component.

Best regards,
Edwin

Mario Giammarco

unread,
Jan 19, 2018, 10:30:19 AM1/19/18
to invesdwin-platform
Sorry I made a mistake! 
"what does it change in rendering if Bar has a BarPage?"

Edwin Stang

unread,
Jan 19, 2018, 10:35:56 AM1/19/18
to invesdwin-platform
The above still explains what it does. Bar can still have a BarPage, a BarPanel or nothing. What is being used and how it is being rendered depends on its usage inside FooPage/FooPanel and how it is included inside Foo.

Code reuse is a concern of the developer and still possible (e.g. by using a BarPanel from everywhere). This behavior provides the most flexibility and control. This is because the Bar html markup might need to be different depending on where it is being rendered, so separate markup might be needed for Page/Panel and as a nested Container.

Edwin Stang

unread,
Jan 19, 2018, 10:41:05 AM1/19/18
to invesdwin-platform
Since BarPage will cause a BarPage.html to be generated (because Bar has the @GeneratedMarkup annotation). A workaround to prevent that is to create a plain BarFacadePage which just contains a BarPanel (can be manual wicket code without a model of its own and without the new GeneratedBinding()... stuff, the NoWIcket stuff will be fully functional inside BarPanel which is a component of BarFacadePage then).
Reply all
Reply to author
Forward
0 new messages