Hi,

Here is a demo app with Wicket 6.x:
https://github.com/martin-g/component-rendering-default

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Oct 13, 2014 at 6:13 PM, Martin Grigorov <[email protected]>
wrote:

> Here is a possible solution *now*:
>
> portletLike.add(new AbstractTransformerBehavior() {
>   @Override public CharSequence transform(Component c, CharSequence
> output) {
>      try {
>        c.internalRenderComponent();
>      } catch (Exception x) {
>        return "default result";
>      }
>    }
> });
>
> Something like this should do it.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Oct 13, 2014 at 5:39 PM, Ernesto Reinaldo Barreiro <
> [email protected]> wrote:
>
>> I see... you may have already streamed content --> Maybe same interface
>> serves to mark a component as "do not stream anything till the end", or
>> stream the contents to an intermediate buffer... but what I way above
>> might
>> not make sense as well.
>>
>>
>> On Mon, Oct 13, 2014 at 4:33 PM, Martin Grigorov <[email protected]>
>> wrote:
>>
>> > On Mon, Oct 13, 2014 at 5:09 PM, Ernesto Reinaldo Barreiro <
>> > [email protected]> wrote:
>> >
>> > > @Martin,
>> > >
>> > > Just a (maybe stupid) idea:
>> > >
>> > > 1- Mark some component as ISafeFail
>> > > 2- If rendering fails take Component_onfail.html and render it
>> > >
>> >
>> > As I said earlier this is not so trivial.
>> > The failure may happen in the middle of the rendering and the content
>> > collected so far in RequestCycle#getResponse() could be invalid HTML.
>> > Appending anything (loaded from a file or generated on the fly) is not
>> > really a solution.
>> >
>> >
>> > >
>> > > On Mon, Oct 13, 2014 at 4:02 PM, Martin Grigorov <
>> [email protected]>
>> > > wrote:
>> > >
>> > > > https://issues.apache.org/jira/browse/WICKET-4321
>> > > > this is the ticker I meant
>> > > > it suggests to restart the rendering completely for the whole page
>> and
>> > > this
>> > > > is not enough
>> > > > I'll see what kind of changes would be needed to accomplish this.
>> > > >
>> > > > Martin Grigorov
>> > > > Wicket Training and Consulting
>> > > > https://twitter.com/mtgrigorov
>> > > >
>> > > > On Fri, Oct 10, 2014 at 2:29 PM, Martin Grigorov <
>> [email protected]
>> > >
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > There is no support for this, even in 7.x.
>> > > > > I remember Carl-Eric Menzel asking for the same functionality
>> before
>> > > ...
>> > > > > Behavior#onException() sounds like something similar but there is
>> no
>> > > way
>> > > > > to suppress the bubbling of the exception at the moment.
>> > > > > The bigger problem is that the rendering can fail in the middle,
>> i.e.
>> > > the
>> > > > > component can have written some response already and then fail. If
>> > the
>> > > > > written response is proper HTML then it is OKish. But if some tag
>> is
>> > > not
>> > > > > closed then the rendering of the complete page may fail.
>> > > > > So if we try to add this functionality we will have to use
>> temporary
>> > > > > Response objects for the rendering of each component to be able to
>> > > throw
>> > > > > away whatever it has produced before failing.
>> > > > >
>> > > > > Usually the problem is related to the component's model. A
>> workaround
>> > > for
>> > > > > you could be to use a wrapper Model that returns "empty data" when
>> > the
>> > > > > underlying model throws an exception.
>> > > > >
>> > > > > Martin Grigorov
>> > > > > Wicket Training and Consulting
>> > > > > https://twitter.com/mtgrigorov
>> > > > >
>> > > > > On Fri, Oct 10, 2014 at 12:59 PM, Ernesto Reinaldo Barreiro <
>> > > > > [email protected]> wrote:
>> > > > >
>> > > > >> Hi,
>> > > > >>
>> > > > >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke <
>> > > > >> [email protected]> wrote:
>> > > > >>
>> > > > >> > Hi,
>> > > > >> >
>> > > > >> >> Wouldn't it be possible to "embed"  the failing prone porlets
>> > > inside
>> > > > >> >> iframes so that each one is a Wicket page?
>> > > > >> >>
>> > > > >> > I already thought about this but the page uses quite a lot of
>> > fancy
>> > > > >> > CSS/Ajax/Javascript (portlets are rendered in a grid with
>> > > configurable
>> > > > >> > row/column count, drag'n'drop to move them around etc.) and I'd
>> > > rather
>> > > > >> not
>> > > > >> > touch the existing code if there's a Java-side only solution
>> ;-)
>> > > > >> >
>> > > > >>
>> > > > >> I do not know of any :-(
>> > > > >>
>> > > > >> Another possibility is build each client entirely on JavaScript
>> and
>> > > use
>> > > > >> Wicket just as a service layer... not very Wicket like but you
>> would
>> > > not
>> > > > >> have this problem.
>> > > > >>
>> > > > >>
>> > > > >> >
>> > > > >> > Cheers,
>> > > > >> > Tobias
>> > > > >> >
>> > > > >> >
>> > > > >> >> On Fri, Oct 10, 2014 at 11:12 AM, Tobias Gierke <
>> > > > >> >> [email protected]> wrote:
>> > > > >> >>
>> > > > >> >>  Hi,
>> > > > >> >>>
>> > > > >> >>> In our web application we have a dashboard-like homepage that
>> > > > >> displays a
>> > > > >> >>> number of user-configurable 'portlets' (which are really just
>> > > > ordinary
>> > > > >> >>> Wicket components and have nothing to do with the Portlet
>> spec).
>> > > I'm
>> > > > >> >>> looking for a way of preventing the application from becoming
>> > > > >> unusable in
>> > > > >> >>> case one or more of these portlets continuously fail to
>> render
>> > > > >> because of
>> > > > >> >>> some internal error/bug.
>> > > > >> >>>
>> > > > >> >>> We're currently using a custom RequestCycleListener with the
>> > > > >> >>> onException()
>> > > > >> >>> method redirecting to a generic error page, thus when
>> rendering
>> > > of a
>> > > > >> >>> 'portlet' fails the user will never get to see the homepage
>> and
>> > > > always
>> > > > >> >>> end
>> > > > >> >>> up on the error page - which is obviously not really
>> desirable.
>> > > > >> >>>
>> > > > >> >>> Is there a way to to hook into Wicket's rendering cycle so
>> that
>> > I
>> > > > can
>> > > > >> >>> provide some default markup in case rendering of a component
>> > > > (subtree)
>> > > > >> >>> fails with a RuntimeException ?
>> > > > >> >>>
>> > > > >> >>> I understand that this maybe be very tricky since the
>> component
>> > > > >> subtree
>> > > > >> >>> might've rendered partially and thus internal state will be
>> > > > >> inconsistent.
>> > > > >> >>> It would probably require serializing the initial state of
>> the
>> > > > >> component
>> > > > >> >>> (subtree) before rendering starts and reverting the wholle
>> > subtree
>> > > > to
>> > > > >> its
>> > > > >> >>> initial state once a RuntimeException is thrown.
>> > > > >> >>>
>> > > > >> >>> We're running Wicket 1.5.12.
>> > > > >> >>>
>> > > > >> >>> Thanks in advance,
>> > > > >> >>> Tobias
>> > > > >> >>>
>> > > > >> >>> --
>> > > > >> >>> Tobias Gierke
>> > > > >> >>> Development
>> > > > >> >>>
>> > > > >> >>> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
>> > > > >> >>> Phone +49 40 688 900 164 Fax +49 40 688 900 199
>> > > > >> >>> Email [email protected]   Web
>> > > http://www.voipfuture.com
>> > > > >> >>>   CEO Jan Bastian
>> > > > >> >>>
>> > > > >> >>> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>>
>> > > >
>> ---------------------------------------------------------------------
>> > > > >> >>> To unsubscribe, e-mail: [email protected]
>> > > > >> >>> For additional commands, e-mail:
>> [email protected]
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>
>> > > > >> >
>> > > > >> >
>> > > ---------------------------------------------------------------------
>> > > > >> > To unsubscribe, e-mail: [email protected]
>> > > > >> > For additional commands, e-mail: [email protected]
>> > > > >> >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> Regards - Ernesto Reinaldo Barreiro
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Regards - Ernesto Reinaldo Barreiro
>> > >
>> >
>>
>>
>>
>> --
>> Regards - Ernesto Reinaldo Barreiro
>>
>
>

Reply via email to