Re: How to deal with vertical tabs?
the fix in 1.5 has caused a bit of havoc as it cascaded to a lot of places, so i dont think we are going to backport it into the stable 1.4. so until you switch to 1.5 you can roll the filter you talked about. -igor On Thu, Jan 27, 2011 at 8:08 AM, Carsten Luckmann wrote: > Hello, > > thank you for your replies. Yes, we are using Wicket 1.4 (I should have > mentioned it in my original post), and unfortunatley, project constraints > prohibit a Wicket upgrade at this time. I shall consider an upgrade as soon > as the project permits. > > Yours, > Carsten > > 2011/1/26 Martin Grigorov > >> This is fixed in 1.5 only. >> >> https://issues.apache.org/jira/browse/WICKET-2264 >> https://issues.apache.org/jira/browse/WICKET-3330 >> >> On Wed, Jan 26, 2011 at 5:10 PM, Igor Vaynberg > >wrote: >> >> > wicket should already be escaping such characters in markup. please >> > file a jira with a quickstart. >> > >> > -igor >> > >> > On Wed, Jan 26, 2011 at 6:36 AM, Carsten Luckmann >> > wrote: >> > > Hello, >> > > >> > > I have a problem with a Wicket Ajax response not being processed. Here >> > the >> > > details: >> > > >> > > I have a link which is supposed to open a ModalWindow. The Ajax request >> > is >> > > sent to the server, processed by the server, and the response is sent >> to >> > the >> > > client. The client receives the response, including the HTML code for >> the >> > > ModalWindow and the JavaScript to open it. Nevertheless, the >> > > Wicket.Window.create call is never executed. After having investigated >> > the >> > > problem, I have found out that this strange behaviour is triggered by a >> > > vertical tab character, which is an illegal XML character and causes >> the >> > XML >> > > parser in Firefox and Chrome to exit (IE works though). This vertical >> tab >> > > character entered the markup from the application's data store and was >> > part >> > > of the content of a data field. >> > > >> > > Until now, I came up with the following strategies: >> > > >> > > 1. One possible solution would be inhibition of illegal XML characters >> in >> > > the data. Besides the question, if this is semantically acceptable, it >> is >> > > difficult and sometimes not possible to intercept and clean all data >> > > entering the data store. >> > > >> > > 2. Another solution would be a Servlet filter, filtering all illegal >> > > characters. The problem I see with this solution is varying character >> > > encoding of the response, which makes it difficult to recognize the >> > illegal >> > > characters in all circumstances. >> > > >> > > 3. My favourite solution would be some kind of mechanism in Wicket, >> which >> > > allows for filtering or modifying the data before the markup is >> rendered. >> > I >> > > just do not know whether there is a way to do this in wicket and how to >> > > perform this task. >> > > >> > > Maybe you can help me and point me into the right direction. Other >> > > suggestions are welcome, too. >> > > >> > > Yours, >> > > Carsten >> > > >> > > -- >> > > Dr. rer. nat. Carsten Luckmann >> > > Dipl.-Phys. >> > > >> > > freiheit.com technologies gmbh >> > > Straßenbahnring 22 / 20251 Hamburg, Germany >> > > fon +49 (0)40 / 890584-0 >> > > fax +49 (0)40 / 890584-20 >> > > HRB Hamburg 70814 >> > > >> > > E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 >> > > Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof >> > > >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> > > > > -- > Dr. rer. nat. Carsten Luckmann > Dipl.-Phys. > > freiheit.com technologies gmbh > Straßenbahnring 22 / 20251 Hamburg, Germany > fon +49 (0)40 / 890584-0 > fax +49 (0)40 / 890584-20 > HRB Hamburg 70814 > > E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 > Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to deal with vertical tabs?
Hello, thank you for your replies. Yes, we are using Wicket 1.4 (I should have mentioned it in my original post), and unfortunatley, project constraints prohibit a Wicket upgrade at this time. I shall consider an upgrade as soon as the project permits. Yours, Carsten 2011/1/26 Martin Grigorov > This is fixed in 1.5 only. > > https://issues.apache.org/jira/browse/WICKET-2264 > https://issues.apache.org/jira/browse/WICKET-3330 > > On Wed, Jan 26, 2011 at 5:10 PM, Igor Vaynberg >wrote: > > > wicket should already be escaping such characters in markup. please > > file a jira with a quickstart. > > > > -igor > > > > On Wed, Jan 26, 2011 at 6:36 AM, Carsten Luckmann > > wrote: > > > Hello, > > > > > > I have a problem with a Wicket Ajax response not being processed. Here > > the > > > details: > > > > > > I have a link which is supposed to open a ModalWindow. The Ajax request > > is > > > sent to the server, processed by the server, and the response is sent > to > > the > > > client. The client receives the response, including the HTML code for > the > > > ModalWindow and the JavaScript to open it. Nevertheless, the > > > Wicket.Window.create call is never executed. After having investigated > > the > > > problem, I have found out that this strange behaviour is triggered by a > > > vertical tab character, which is an illegal XML character and causes > the > > XML > > > parser in Firefox and Chrome to exit (IE works though). This vertical > tab > > > character entered the markup from the application's data store and was > > part > > > of the content of a data field. > > > > > > Until now, I came up with the following strategies: > > > > > > 1. One possible solution would be inhibition of illegal XML characters > in > > > the data. Besides the question, if this is semantically acceptable, it > is > > > difficult and sometimes not possible to intercept and clean all data > > > entering the data store. > > > > > > 2. Another solution would be a Servlet filter, filtering all illegal > > > characters. The problem I see with this solution is varying character > > > encoding of the response, which makes it difficult to recognize the > > illegal > > > characters in all circumstances. > > > > > > 3. My favourite solution would be some kind of mechanism in Wicket, > which > > > allows for filtering or modifying the data before the markup is > rendered. > > I > > > just do not know whether there is a way to do this in wicket and how to > > > perform this task. > > > > > > Maybe you can help me and point me into the right direction. Other > > > suggestions are welcome, too. > > > > > > Yours, > > > Carsten > > > > > > -- > > > Dr. rer. nat. Carsten Luckmann > > > Dipl.-Phys. > > > > > > freiheit.com technologies gmbh > > > Straßenbahnring 22 / 20251 Hamburg, Germany > > > fon +49 (0)40 / 890584-0 > > > fax +49 (0)40 / 890584-20 > > > HRB Hamburg 70814 > > > > > > E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 > > > Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > -- Dr. rer. nat. Carsten Luckmann Dipl.-Phys. freiheit.com technologies gmbh Straßenbahnring 22 / 20251 Hamburg, Germany fon +49 (0)40 / 890584-0 fax +49 (0)40 / 890584-20 HRB Hamburg 70814 E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof
Re: How to deal with vertical tabs?
This is fixed in 1.5 only. https://issues.apache.org/jira/browse/WICKET-2264 https://issues.apache.org/jira/browse/WICKET-3330 On Wed, Jan 26, 2011 at 5:10 PM, Igor Vaynberg wrote: > wicket should already be escaping such characters in markup. please > file a jira with a quickstart. > > -igor > > On Wed, Jan 26, 2011 at 6:36 AM, Carsten Luckmann > wrote: > > Hello, > > > > I have a problem with a Wicket Ajax response not being processed. Here > the > > details: > > > > I have a link which is supposed to open a ModalWindow. The Ajax request > is > > sent to the server, processed by the server, and the response is sent to > the > > client. The client receives the response, including the HTML code for the > > ModalWindow and the JavaScript to open it. Nevertheless, the > > Wicket.Window.create call is never executed. After having investigated > the > > problem, I have found out that this strange behaviour is triggered by a > > vertical tab character, which is an illegal XML character and causes the > XML > > parser in Firefox and Chrome to exit (IE works though). This vertical tab > > character entered the markup from the application's data store and was > part > > of the content of a data field. > > > > Until now, I came up with the following strategies: > > > > 1. One possible solution would be inhibition of illegal XML characters in > > the data. Besides the question, if this is semantically acceptable, it is > > difficult and sometimes not possible to intercept and clean all data > > entering the data store. > > > > 2. Another solution would be a Servlet filter, filtering all illegal > > characters. The problem I see with this solution is varying character > > encoding of the response, which makes it difficult to recognize the > illegal > > characters in all circumstances. > > > > 3. My favourite solution would be some kind of mechanism in Wicket, which > > allows for filtering or modifying the data before the markup is rendered. > I > > just do not know whether there is a way to do this in wicket and how to > > perform this task. > > > > Maybe you can help me and point me into the right direction. Other > > suggestions are welcome, too. > > > > Yours, > > Carsten > > > > -- > > Dr. rer. nat. Carsten Luckmann > > Dipl.-Phys. > > > > freiheit.com technologies gmbh > > Straßenbahnring 22 / 20251 Hamburg, Germany > > fon +49 (0)40 / 890584-0 > > fax +49 (0)40 / 890584-20 > > HRB Hamburg 70814 > > > > E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 > > Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: How to deal with vertical tabs?
wicket should already be escaping such characters in markup. please file a jira with a quickstart. -igor On Wed, Jan 26, 2011 at 6:36 AM, Carsten Luckmann wrote: > Hello, > > I have a problem with a Wicket Ajax response not being processed. Here the > details: > > I have a link which is supposed to open a ModalWindow. The Ajax request is > sent to the server, processed by the server, and the response is sent to the > client. The client receives the response, including the HTML code for the > ModalWindow and the JavaScript to open it. Nevertheless, the > Wicket.Window.create call is never executed. After having investigated the > problem, I have found out that this strange behaviour is triggered by a > vertical tab character, which is an illegal XML character and causes the XML > parser in Firefox and Chrome to exit (IE works though). This vertical tab > character entered the markup from the application's data store and was part > of the content of a data field. > > Until now, I came up with the following strategies: > > 1. One possible solution would be inhibition of illegal XML characters in > the data. Besides the question, if this is semantically acceptable, it is > difficult and sometimes not possible to intercept and clean all data > entering the data store. > > 2. Another solution would be a Servlet filter, filtering all illegal > characters. The problem I see with this solution is varying character > encoding of the response, which makes it difficult to recognize the illegal > characters in all circumstances. > > 3. My favourite solution would be some kind of mechanism in Wicket, which > allows for filtering or modifying the data before the markup is rendered. I > just do not know whether there is a way to do this in wicket and how to > perform this task. > > Maybe you can help me and point me into the right direction. Other > suggestions are welcome, too. > > Yours, > Carsten > > -- > Dr. rer. nat. Carsten Luckmann > Dipl.-Phys. > > freiheit.com technologies gmbh > Straßenbahnring 22 / 20251 Hamburg, Germany > fon +49 (0)40 / 890584-0 > fax +49 (0)40 / 890584-20 > HRB Hamburg 70814 > > E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 > Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
How to deal with vertical tabs?
Hello, I have a problem with a Wicket Ajax response not being processed. Here the details: I have a link which is supposed to open a ModalWindow. The Ajax request is sent to the server, processed by the server, and the response is sent to the client. The client receives the response, including the HTML code for the ModalWindow and the JavaScript to open it. Nevertheless, the Wicket.Window.create call is never executed. After having investigated the problem, I have found out that this strange behaviour is triggered by a vertical tab character, which is an illegal XML character and causes the XML parser in Firefox and Chrome to exit (IE works though). This vertical tab character entered the markup from the application's data store and was part of the content of a data field. Until now, I came up with the following strategies: 1. One possible solution would be inhibition of illegal XML characters in the data. Besides the question, if this is semantically acceptable, it is difficult and sometimes not possible to intercept and clean all data entering the data store. 2. Another solution would be a Servlet filter, filtering all illegal characters. The problem I see with this solution is varying character encoding of the response, which makes it difficult to recognize the illegal characters in all circumstances. 3. My favourite solution would be some kind of mechanism in Wicket, which allows for filtering or modifying the data before the markup is rendered. I just do not know whether there is a way to do this in wicket and how to perform this task. Maybe you can help me and point me into the right direction. Other suggestions are welcome, too. Yours, Carsten -- Dr. rer. nat. Carsten Luckmann Dipl.-Phys. freiheit.com technologies gmbh Straßenbahnring 22 / 20251 Hamburg, Germany fon +49 (0)40 / 890584-0 fax +49 (0)40 / 890584-20 HRB Hamburg 70814 E5FA C55C A15B 27CB 0EEE D4F5 F8DE 4DBD 524A F375 Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof
