[Zope3-dev] Re: [Zip] [Zip]Re: About Zope3 HTTP-input handling

[Tino Wildenhain]

Hi Heiichiro,

I actually dont understand the use of more then one locales
object in the tree. This looks like you want different parts
of the site having different languages and stuff.

My opinion is more like the HTTP language negotiation (rfc2616)
thinks about it: every variant should transparently be accessible
at the same URL. The philosophy is: different content: different URL,
same content (but many representations, say language/encoding variants)
same URL.

So for simple documents we have the following flow:

browser(Settings) -> server(Variants of page),decodes desired variants(from 
request)and encoding(from request), chooses best, then serves content
during content creation, there is somewhat "static" content, which
gets choosed (for example a localized ZPT subobject) and all
dynamic content gets the decision of the publisher from Request (current 
language
and encoding) and should provide its information accordingly
(for example looking up the right language in a database for reply,
formating numbers accordingly (unless specific overridden if page
splits in dynamic language area and fixed language area)

then publisher returns whole page with matching encoding.

Dynamic pages (forms) are like this, but when form returns from
browser, the former encoding should be taken in account
either by saving it in the form data or making the same decision
like when sending the form HTML or even with heuristic.

in REQUEST.form there whould be plain unicode data of form data
returned by the browser - so we would have a clean consistent interface.

This all would unburden the application developer from worries about
specific encodings and handling of different language specifica.

Regards
Tino


--On Mittwoch, 23. Oktober 2002 12:32 -0700 Heiichiro NAKAMURA 
<nheiich@quantumfusion.com> wrote:

>
> On Wed, 16 Oct 2002 21:08:34 -0700
> Heiichiro NAKAMURA <nheiich@quantumfusion.com> wrote:
>
>> I just typed-in what in my head about I18N/M17N in:
>>
>> http://dev.zope.org/Members/nheiich/drafts/z3_i18n_d1
>
>
>
> After then I tried to find what is the realistic milestones.
> (I put it there, it's incomplete though.)
> http://www.zope.org/Members/nheiich/drafts/draft_milestones
>
>
> I also write some pseudo code to describe the idea, just FYI:
> http://www.zope.org/Members/nheiich/drafts/loc_pseudoCode_py
>
> Anyway,
> while I'm trying to implement a mock-up prototype to investigate
> feasibility, I encountered the following problem:
>
> Does anyone know any clue for it?
>
>
> It shouldn't very hard to acquire the "Locale" object from
> the published object and convert the output in HTTPResponse
> to appropriate to text encoded data, since everything required
> to do so is already there (authentication, access right, the published
>  object, etc).
>
> However, I couldn't convert HTTP-Input-data with "Locale" object
> because the HTTP-Input-data (HTTPRequest) is parsed first
> in ZPublisher/Publish.py#publish()::
>
>         request.processInputs()
>
> then get the published object::
>
>         object=request.traverse(path, validated_hook=validated_hook)
>
>
> What I wanted to do is:
>
>  1. get the published object
>  2. locate and acquire the nearest "Locale" Object from the published
> object  3. parse input data with locale object (request.processInputs())
>
>
> Regards,
> ---
> Heiichiro NAKAMURA <nheiich@quantumfusion.com>
>
>
> _______________________________________________
> Zip mailing list
> Zip@zope.org
> http://lists.zope.org/mailman/listinfo/zip