Re: Returning some default markup when rendering of a component (subtree) fails with a RuntimeException ?
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 <
reier...@gmail.com> 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
> wrote:
>
> > On Mon, Oct 13, 2014 at 5:09 PM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> 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 >
> > > 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 <
> mgrigo...@apache.org
> > >
> > > > 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 <
> > > > > reier...@gmail.com> wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke <
> > > > >> tobias.gie...@voipfuture.com> 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 <
> > > > >> >> tobias.gie...@voipfuture.com> 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
> > > > >> >>>
Re: Returning some default markup when rendering of a component (subtree) fails with a RuntimeException ?
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 wrote: > On Mon, Oct 13, 2014 at 5:09 PM, Ernesto Reinaldo Barreiro < > reier...@gmail.com> 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 > > 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 > > > > 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 < > > > > reier...@gmail.com> wrote: > > > > > > > >> Hi, > > > >> > > > >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke < > > > >> tobias.gie...@voipfuture.com> 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 < > > > >> >> tobias.gie...@voipfuture.com> 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 m
Re: Returning some default markup when rendering of a component (subtree) fails with a RuntimeException ?
On Mon, Oct 13, 2014 at 5:09 PM, Ernesto Reinaldo Barreiro < reier...@gmail.com> 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 > 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 > > 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 < > > > reier...@gmail.com> wrote: > > > > > >> Hi, > > >> > > >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke < > > >> tobias.gie...@voipfuture.com> 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 < > > >> >> tobias.gie...@voipfuture.com> 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 >
Re: Returning some default markup when rendering of a component (subtree) fails with a RuntimeException ?
@Martin, Just a (maybe stupid) idea: 1- Mark some component as ISafeFail 2- If rendering fails take Component_onfail.html and render it On Mon, Oct 13, 2014 at 4:02 PM, Martin Grigorov 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 > 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 < > > reier...@gmail.com> wrote: > > > >> Hi, > >> > >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke < > >> tobias.gie...@voipfuture.com> 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 < > >> >> tobias.gie...@voipfuture.com> 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 tobias.gie...@voipfuture.com Web http://www.voipfuture.com > >> >>> CEO Jan Bastian > >> >>> > >> >>> Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 > >> >>> > >> >>> > >> >>> > >> >>> > - > >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> >>> For additional commands, e-mail: users-h...@wicket.apache.org > >> >>> > >> >>> > >> >>> > >> >> > >> > > >> > --
Re: Returning some default markup when rendering of a component (subtree) fails with a RuntimeException ?
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 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 < > reier...@gmail.com> wrote: > >> Hi, >> >> On Fri, Oct 10, 2014 at 11:50 AM, Tobias Gierke < >> tobias.gie...@voipfuture.com> 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 < >> >> tobias.gie...@voipfuture.com> 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 tobias.gie...@voipfuture.com Web http://www.voipfuture.com >> >>> CEO Jan Bastian >> >>> >> >>> Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086 >> >>> >> >>> >> >>> >> >>> - >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >>> >> >>> >> >> >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> >> >> -- >> Regards - Ernesto Reinaldo Barreiro >> > >
Re: Could not clear select2Choice component model value.
Maxim,
Feel free to fork it! I.e. move it to WicketStuff.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 9, 2014 at 8:53 PM, Maxim Solodovnik
wrote:
> Additionally select2 seems to need to be forked to wicketstuff to be fixed,
> should I do this?
>
> On 10 October 2014 00:49, Maxim Solodovnik wrote:
>
> > @Paul, @Martin
> >
> > Select2Choice sets back its value
> > to getWebRequest().getRequestParameters().getParameterNames()
> > in renderInitializationScript method [1]
> > It seems like JS code like: $("#country1").select2("data", null); can be
> > executed on clear input, but this seems to be workaround
> >
> > I'm not sure why [1] method is used to get value, maybe you can suggest
> > correct way of fixing this?
> >
> >
> > [1]
> >
> https://github.com/ivaynberg/wicket-select2/blob/master/wicket-select2/src/main/java/com/vaynberg/wicket/select2/Select2Choice.java#L62
> >
> > On 9 October 2014 16:39, MadasamySankarapandian
> > wrote:
> >
> >> Thanks Maxim Solodovnik.
> >>
> >> On Thu, Oct 9, 2014 at 12:33 PM, Maxim Solodovnik >
> >> wrote:
> >>
> >> > I also noticed this issue in our project,
> >> > Will try to take a look at it
> >> >
> >> > On 9 October 2014 07:33, MadasamySankarapandian <
> madas...@mcruncher.com
> >> >
> >> > wrote:
> >> >
> >> > > Thankyou very much for yours reply.
> >> > >
> >> > > I call formComponent.clearInput() in my ClearFormVisitor class. But
> It
> >> > does
> >> > > not work.
> >> > > I have created issue-96
> >> > > in
> >> > wicket-select2
> >> > > project.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Oct 8, 2014 at 12:13 AM, Maxim Solodovnik <
> >> solomax...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Done, thanks for pointing this out
> >> > > >
> >> > > > On 7 October 2014 23:08, Paul Bors wrote:
> >> > > >
> >> > > > > Can you update this issue then?
> >> > > > >
> >> > > > > https://github.com/ivaynberg/wicket-select2/issues/93
> >> > > > >
> >> > > > > On Tue, Oct 7, 2014 at 12:00 PM, Maxim Solodovnik <
> >> > > solomax...@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > we recently moved this component to wicketstuff:
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/select2-parent
> >> > > > > >
> >> > > > > > to get Wicket7 compatible version
> >> > > > > >
> >> > > > > >
> >> > > > > > On 7 October 2014 22:56, Paul Bors wrote:
> >> > > > > >
> >> > > > > > > You can also ask the developer via:
> >> > > > > > > https://github.com/ivaynberg/wicket-select2/issues
> >> > > > > > >
> >> > > > > > > You should probably take a look over the open issues so that
> >> you
> >> > > are
> >> > > > > > > familiar with that other developers faced. Maybe one of
> those
> >> > > issues
> >> > > > > > might
> >> > > > > > > be a road block for you?
> >> > > > > > >
> >> > > > > > > Although you will get a faster reply from Igor or another
> >> Wicket
> >> > > > > > developer
> >> > > > > > > via this list :)
> >> > > > > > >
> >> > > > > > > On Tue, Oct 7, 2014 at 4:23 AM, Martin Grigorov <
> >> > > > mgrigo...@apache.org>
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > Hi,
> >> > > > > > > >
> >> > > > > > > > You should call formComponent.clearInput() too.
> >> > > > > > > >
> >> > > > > > > > Martin Grigorov
> >> > > > > > > > Wicket Training and Consulting
> >> > > > > > > > https://twitter.com/mtgrigorov
> >> > > > > > > >
> >> > > > > > > > On Tue, Oct 7, 2014 at 9:13 AM, MadasamySankarapandian <
> >> > > > > > > > madas...@mcruncher.com> wrote:
> >> > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > This is regarding wicket-select2 project. I could not
> find
> >> > any
> >> > > > > > mailing
> >> > > > > > > > > list for this project. That is why sending here. Please
> >> some
> >> > > one
> >> > > > > help
> >> > > > > > > me.
> >> > > > > > > > >
> >> > > > > > > > > I have created clear link to clear the form input
> values.
> >> > After
> >> > > > > click
> >> > > > > > > the
> >> > > > > > > > > clear link, all components values are cleared except
> >> > > > Select2Choice
> >> > > > > > > > > component.
> >> > > > > > > > >
> >> > > > > > > > > Here with attached quickstart to recreate this problem.
> >> > > > > > > > >
> >> > > > > > > > > Follow below steps to recreate this problem
> >> > > > > > > > >
> >> > > > > > > > > * Download attachment and extract it.
> >> > > > > > > > > * cd select2-quickstart.
> >> > > > > > > > > * Then execute mvn clean package jetty:run
> >> > > > > > > > > * Type localhost:8080 in browser
> >> > > > > > > > > * Give the input to name and country field.
> >> > > > > > > > > * Click clear link
> >> > > > > > > > >
> >> > > > > > > > > Now name(*TextField*) field value is cleared and
> >> > > > > > > country(*Select2Choice*)
> >> > > > > > > > > field value is not cleared.
> >> > >
Re: [7.0.0-SNAPSHOT] WebSocketResponse#sendError throws UnsupportedOperationException
Hi Martin,
If #sendError() is called on purpose, then you are right it should not be
ignored
Sadly, I do not have many time to investigate more on this and try to
understand the exact behavior and the relationship with the error thrown on
my side. (It was part of a PoC I'm not supposed to work on for now...)
I will let you know if I have some news...
Thanks again & best regards,
Sebastien.
On Fri, Oct 10, 2014 at 5:59 PM, Martin Grigorov
wrote:
> On Fri, Oct 10, 2014 at 6:40 PM, Sebastien wrote:
>
> > Hi Martin,
> >
> > Thanks for your quick answer!
> >
> > Just to be sure we are on the same page, I do not call #sendError
> myself...
> > I suppose it is called automatically because an exception is thrown
> > elsewhere (let's considering this is the intended behavior in my
> case...).
> >
> > > One option is to replace "throw UnsupportedOperationException" with
> > log.warn.
> > I would personally just have replaced "throw new
> > UnsupportedOperationException()" by a "// noop" comment or something like
> > that. Logging a warning would mean the user can take an action to correct
> > this but - if I understood you correctly - that's not the case...
> >
>
> But do you really want the exception to be swallowed like this ?
> This will lead to a lot of confusion - an error happens and Wicket neither
> logs it nor sends any feedback back to the browser ...
>
>
> >
> > Checking that target IS-A WebSocketRequestHandler will be probably very
> > useful in a near future! :)
> >
> > Best regards,
> > Sebastien.
> >
> >
> > On Fri, Oct 10, 2014 at 5:21 PM, Martin Grigorov
> > wrote:
> >
> > > Hi Sebastien,
> > >
> > > With https://issues.apache.org/jira/browse/WICKET-5701 I've added
> > support
> > > for RequestCycle.find(AjaxRequestTarget.class) and actually proper
> > support
> > > for scheduling any kind of IRequestHandler.
> > > In M3 your ErrorCodeRequestHandler has been just send to /dev/null.
> > >
> > > One option is to replace "throw UnsupportedOperationException" with
> > > log.warn.
> > > The idea is that your error code doesn't mean anything in the web
> socket
> > > response. It is not normal HTTP response so the browser won't try to
> > > process it ...
> > >
> > > In your code you can check whether this is a WebSocketRequestHandler
> and
> > > return something that your client side logic should process as an
> error.
> > > Or maybe WebSocketResponse.sendError() can write this for you: {"type":
> > > "error", "code": 456, "message": "optional"} ?
> > > But again it is up to your client side logic to process it.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Fri, Oct 10, 2014 at 6:09 PM, Sebastien wrote:
> > >
> > > > Hi,
> > > >
> > > > Using 7.0.0-SNAPSHOT, I've got a UnsupportedOperationException (see
> > > below)
> > > > whereas I do not have it on 7.0.0-M3. I don't really know how to
> > > > investigate as an UnsupportedOperationException seems to be the
> > expected
> > > > result [1], or maybe #sendError is not supposed to be called anyway,
> or
> > > it
> > > > is a regression from -M3...
> > > >
> > > > I'm using wicket-native-websocket-core &
> wicket-native-websocket-javax
> > on
> > > > WildFly8
> > > >
> > > > Thanks in advance for your advise,
> > > > Sebastien.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/WebSocketResponse.java#L193
> > > >
> > > > --
> > > > ERROR [org.apache.wicket.request.cycle.RequestCycle] Error during
> > > > processing error message: java.lang.UnsupportedOperationException
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.protocol.ws.api.WebSocketResponse.sendError(WebSocketResponse.java:193)
> > > > [wicket-native-websocket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.http.handler.ErrorCodeRequestHandler.respond(ErrorCodeRequestHandler.java:77)
> > > > [wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:837)
> > > > [wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> > > > [wicket-request-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:314)
> > > > [wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:323)
> > > > [wicket-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.wicket.request.cycle.Req
Re: DataView, OrderByBorder, CheckGroup
Hi, On Mon, Oct 13, 2014 at 2:59 AM, Colin Rogers < colin.rog...@objectconsulting.com.au> wrote: > Wicketeers, > > I don't know if this is a bug, bad coding on my behalf or incompatible > components or what not. It's only a minor thing, but I thought it worth > raising (as usually, I end up learning something). > > I've created a quickstart, here; > > http://tenthart.com/wickettest2.zip > > The basic thing is that I have a DataView, with columns organised with an > OrderByBorder component. Wrapping those, I have a CheckGroup. It's the > CheckGroup that seems to trigger a weird behaviour in that the pageId > doesn't increment when the OrderByBorder link is clicked. This has the > knock on that StalePageException are raised (and handled) when going back > through history or more often, when opening links in new window (click > 'open in new window' and then click the link again the original window). > The affects are minor - the page refreshing and the click being ignored, so > nothing majorly important. > When you copy the url from the address bar from one tab/window to another the page id stays the same but another special counter changes - Page#renderCount. When you load the page in the second tab/window the renderCount increments with 1. If you use non-Ajax components/behaviors to interact with the page it may increment even more. Later when you go back to the first tab/window and try to use any component (Ajax or not) Wicket will check whether the the renderCount in the request url (e.g. in '3-1-ILinkListener~some~component' '3' is the pageId and '1' is the renderCount) matches with the renderCount of the page with id 3 in the pages' store. If it doesn't then a special PageStaleException is being thrown and Wicket just renders the page with its latest state and respectively renderCount+1. This is needed to prevent using stale/obsolete version of the page. E.g. if in the second tab/window you remove a panel for some entity and this panel contains a child component a link to edit this entity then trying to click on this link in the first tab/window will end with ComponentNotFoundException if there was no such check. > > Also, as an aside, the Wicket Debug box seems to have disappeared. > I haven't checked what is the reason for this to disappear. But above you listed only non-Ajax components. The Ajax debug window appears only if there is an Ajax behavior in the rendered page. Lately I don't see any usefulness in Ajax Debug Window. All the information is available in the browser's Dev tools. > > Anyway, has anyone got advice on this? Is it a bug? > > Cheers, > Col. > EMAIL DISCLAIMER This email message and its attachments are confidential > and may also contain copyright or privileged material. If you are not the > intended recipient, you may not forward the email or disclose or use the > information contained in it. If you have received this email message in > error, please advise the sender immediately by replying to this email and > delete the message and any associated attachments. Any views, opinions, > conclusions, advice or statements expressed in this email message are those > of the individual sender and should not be relied upon as the considered > view, opinion, conclusions, advice or statement of this company except > where the sender expressly, and with authority, states them to be the > considered view, opinion, conclusions, advice or statement of this company. > Every care is taken but we recommend that you scan any attachments for > viruses. >
