[html-formfu] very, very slow initially

[Mario Minati]

On Wednesday 26 September 2007 22:13:52 Josef Chladek wrote:
> Am 26.09.2007 um 22:06 schrieb Mario Minati:
> > On Wednesday 26 September 2007 21:52:29 Josef Chladek wrote:
> >> Am 26.09.2007 um 21:04 schrieb Josef Chladek:
> >>>>> 2) encoding is broken and I have garbled umlauts again (with and
> >>>>> without the Catalyst::Plugin::Unicode) - I even tried the Test-
> >>>>> app (I
> >>>>> sent yesterday to the list), and the Umlauts don't show up
> >>>>> correctly
> >>>>
> >>>> Sorry, I haven't had a chance to look at your app yet.
> >>>> I think it's a case of encoding is *still* broken - from your
> >>>> description, there's definitely something wrong.
> >>>
> >>> well I was too fast, the Test-app works with utf8 (execpt that
> >>> error messages are iso as described yesterday). I'll look deeper in
> >>> my Catalyst app (and all the plugins) to describe the behaviour
> >>> better...
> >>
> >> it seems, that the use of
> >>
> >> Catalyst::Plugin::Compress::Gzip
> >>
> >> in combination with HTLM::FormFu leads to bad utf-8, if I uncomment
> >> it in my setup, everything's ok
> >
> > Kind of good news (for FormFu) ;-)
> >
> > If you use apache can't you tell apache to do the compression?
>
> yes, but for our config we could not get compression to work for the
> fastcgi-handler through apache (although it works for all other
> stuff), so I moved that part to Catalyst. any chance that formfu will
> play nicely with C:P:Compress:Gzip? there is not a lot happening in
> that plugin, but I can't figure out what runs wrong...
> thanks
> josef

How can we sure where the problem is?

Through the compression the content type is changed so the problem might be 
beyond the scope of FormFu or even out of Catalyst.

When I rember correctly, the result of form.render was fine itself.
What happens if you send some utf8 data without usage of FormFu?

Anyway, Carl is the unicode expert.

Greets,
Mario