Hi Martijn,

I have two problems with your filter:
1) The main problem is that our pages does not have XHTML doctype.
The pages are XML well formed but this is not enough.
I tried once to set this doctype and the browsers rendered them in a
very funny (and broken) way. The HTML and probably CSS will need some
work to make it XHTML complaint.

2) do you really use Maven 'test' scope for this dependency ?
MyApp.java is not in src/test/java and thus cannot see
HtmlValidationResponseFilter.
Changing the scope to 'provided' fixes the problem.
This way I need to remove the 'import' and provide fully qualified path
to the filter class inside "if (development)". This works fine in Jetty
(development) and is not being packaged in the .war for production.

Unfortunately problem 1) is not resolvable for me and I cannot use the
filter.

Thanks !     

On Wed, 2010-03-17 at 09:01 +0100, Martijn Dashorst wrote:
> Shameless plug (but it has helped our company's HTML considerably):
> 
> You could consider using the html validator filter for that
> (http://github.com/dashorst/wicket-stuff-markup-validator)
> 
> Martijn
> 
> On Tue, Mar 16, 2010 at 6:10 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
> wrote:
> > i have seen that happen when you have invalid markup. like a div
> > inside a span, or a div directly inside a tr. check your page for
> > stuff like that.
> >
> > -igor
> >
> > On Tue, Mar 16, 2010 at 10:02 AM, Martin Grigorov <mcgreg...@e-card.bg> 
> > wrote:
> >> Hi,
> >>
> >> I'm experiencing a weird problem with Wicket Ajax in Firefox 3.6 (I
> >> didn't test in older versions of FF).
> >>
> >> Basically my code looks like this:
> >>
> >> final TextField<String> textField = new TextField<String>("text", new
> >> PropertyModel<String>(this, "text"));
> >> textField.setOutputMarkupId(true);
> >> textField.setOutputMarkupPlaceholderTag(true);
> >> textField.setVisible(false);
> >>
> >> add(textField);
> >>
> >> final AjaxLink<Void> link = new AjaxLink<Void>("link") {
> >>        private static final long serialVersionUID = 1L;
> >>
> >>        boolean toShow = true;
> >>
> >>        @Override
> >>        public void onClick(AjaxRequestTarget target) {
> >>                textField.setVisible(toShow);
> >>                toShow = !toShow;
> >>                target.addComponent(textField);
> >>        }
> >> };
> >>
> >> and the html :
> >> <div>
> >>        <input wicket:id="text"/>
> >> </div>
> >> <a wicket:id="link">link</a>
> >>
> >> The basic idea is to switch the visibility of a TextField, the initial
> >> state is not visible.
> >>
> >> This works pretty well in IE (tested in 7 and 8) and Chrome (tested with
> >> ver.5 on Linux).
> >> Unfortunately the most reliable browser makes something very weird -
> >> every re-render with visibility==true it appends one more <div> element
> >> around the <input> element:
> >>
> >> <div>  (this is my <div> from the template)
> >>  <div xmlns="http://www.w3.org/1999/xhtml";>  (this one is added by FF)
> >>     <div xmlns="http://www.w3.org/1999/xhtml";> (this one is added by
> >> FF)
> >>       <input id="text2e" name="...." value="..."/>
> >>     </div>
> >>  </div>
> >> </div>
> >>
> >> I created a simple quickstart application and there everything is
> >> working fine. So it looks to me that FF confuses somehow with the
> >> complex html structure of my page.
> >>
> >> Did anyone have such problems before ?
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> 
> 
> 



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

Reply via email to