as well.
> but it indicates that you're using a field element without a name -
> this is unsupported by FormFu, and may cause other errors.
Thanks for the tip. I'll check.
--
Regards,
Bjørn-Helge Mevik
___
List: Catalyst@lists.s
|
| poststed| |
| rekr_kommentar | |
| rekruttering| nei
uably a FormFu problem, but
FormFu is important for Catalyst applications. :-)
--
Bjørn-Helge Mevik
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com
eparately and you can use different encoding (like UTF-8 for the
> web pages and Latin-1 for the DB).
I heartily agree. Unfortunately, sofar I haven't been able to figure
out how to get the proper encode()/decode() when using
Catalyst::Model::DBIC::Schema.
--
Bjørn-Helge Mevik
___
(A.K.A. my home computer :-).
--
Bjørn-Helge Mevik
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk
s, I think :-): All characters are
displayed correctly (as UTF-8), but non-ASCII characters entered into
a form gets stored as UTF-8 in mysql.
So perhaps my best bet now is to try and get my data properly encoded
on the way to mysql?
--
Bjørn-Helge Mevik
__
t in the different
print()s.
>From this it would seem that Apache and mod_perl do not recode the
characters. Perhaps it could be something that TT does when run under
mod_perl (as this does not happen under the development server)?
--
Bjørn-Helge Mevik
__
about this? Can I tell mod_perl to "leave my characters
alone"? Have I made an error somewhere?
--
Regards,
Bjørn-Helge Mevik
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchab
