wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: Programmatic Markup with fallback
Date Tue, 16 Sep 2014 10:28:06 GMT
So, I have a working solution like this:

public class CustomMarkupFallbackMarkupContainer extends
WebMarkupContainer implements IMarkupCacheKeyProvider {
    public CustomMarkupFallbackMarkupContainer(String id,
IModel<String> model) {super(id, model);}

    public IMarkupFragment getMarkup() {
        String markupString = (String) getDefaultModelObject();
        if (markupString == null) {
            return getAssociatedMarkup();
        } else {
            return Markup.of(markupString);

    @Override public String getCacheKey(MarkupContainer container,
Class<?> containerClass) {return null;}

Regarding the multiple invocations of getMarkup(), they also occur
when caching, and indeed they occur on every request (caching happens
only for the associated markup, I assume). The calls all happen inside
the same call to Component.internalRender()

Invocations are:
1: Component.internalRender():2309 // creating a MarkupStream only
used inside if block

Component.internalRenderComponent():2472 // some duplicate code with
MarkupContainer.onRender(): 1496

MarkupContainer.onRender(): 1496

MarkupContainer.onRender(): 1496

Regarding usage of onComponentTagBody(), that seems also valid, but
much deeper into the Wicket API than I would want to go, in particular
given there are recommended solutions in
http://wicket.apache.org/guide/guide/advanced.html#advanced_5 and the

On Tue, Sep 16, 2014 at 12:00 PM, Andrea Del Bene <an.delbene@gmail.com> wrote:
> Hi,
> I didn't dig to much into the code, but keep in mind that you are disabling
> markup caching in your example. This might explain why getMarkup is called
> three times.
> Anyway, in your specific case it might be better not to implement
> IMarkupCacheKeyProvider and IMarkupResourceStreamProvider, but simply
> override onComponentTagBody like this:
> @Override
>     public void onComponentTagBody(MarkupStream markupStream, ComponentTag
> openTag) {
>         if (getDefaultModelObject() == null) {
>             super.onComponentTagBody(markupStream, openTag);
>         }
>         else {
>             replaceComponentTagBody(markupStream, openTag, "<wicket:panel>it
> works</wicket:panel>");
>         }
>     }
>> So debugging a bit, I find that I get hit by the
>> PanelMarkupSourcingStrategy. It seems it throws away the body markup
>> in favcor of the associated Markup. So I could advance one step by
>> extending WebMarkupContainer instead of Panel.
>> I notice that when extending Panel, getMarkup() is being called 3
>> times in my example, before the result is being discarded.
>> That seems like design smell. If users override getMarkup() with some
>> expensive operation, they should be able to rely on this being called
>> just once, and this only if the result is actually being used.
>> On Tue, Sep 16, 2014 at 11:24 AM, Thibault Kruse
>> <tibokruse@googlemail.com> wrote:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org

To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

View raw message