I have not had a chance to look at Julian's work, but we'll be watching these developments. One of the most frequent question we get from would-be JRuby users is "why don't you support unicode." We want to...we really do.
On 6/11/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote:
On 11-jun-2006, at 14:56, Mislav Marohnić wrote:
> That is some nice work here, Julian. Proxy access makes this
> possible to adopt while not breaking anything - I would, too, like
> to see this someday _without_ a proxy.
>
> I have a question and a request that aren't really about the hacks
> (I would leave that to more experienced programmers) but about the
> plugin. First, about 'db_unicode_client.rb' - isn't this
> functionality (setting client encoding) already present by
> specifying 'encoding' attribute in database.yml? Second: when
> setting "content-type" header for output, could you not force text/
> html but put in a variable which value defaults to text/html so we
> can provide 'application/xhtml+xml' or other content types in
> specific controllers?
>
> Sorry to bug you with such somewhat not very relevant issues, but I
> feel that this needs to be a truly universally droppable plugin and
> these kind of minor tweaks will make it such.
unicode_hacks has to go, if the core will agree for the chars proxy.
As to the encoding configuration, this has to be done in the
connection adapters - the reason being, I haven't yet met an
implementation (either in Perl or PHP or Python - and I suspect AR is
no different) that would maintain a client encoding should the
connection "go away" (it means "do another query when you have to
reconnect"). Rails uses persistent connections right now, meaning
that without this I am insecure from having my NAMES reset to
something I really didn't want when the connection needs to be
reestablished (and it's common for SQL sockets on shareds to
timeout). This has to be handled by ActiveRecord's adapters IMO (if
it's not handled already).
As to the headers, Rails should just default for utf-8 headers when
$KCODE is UTF for both xml, rjs and html. See a ticket on this:
http://dev.rubyonrails.org/ticket/4975
All of this can be implemented and tested in a backwards-compatible
way and friendly for (for example) Japanese folks that want their
$KCODE set to JIS and friends, or German people who tend to rely on
ISO. The Chars abstraction also caters for this requirement by always
checking $KCODE.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________ Rails-core mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-core
