[Chandler-dev] Re: Request for Coments on Chandler
Internationalization / Egg Integration Proposal
mmmm at osafoundation.org
Tue Jul 25 12:53:50 PDT 2006
>> * I saw no documentation about the direct file access to resources
>> in eggs, which is provided through wx.FileSystem. I think that this
>> is a cool and easy way to access resources and as I assume that this
>> service is still available, I would like to see this part of the
>> documentation/proposal improved. Otherwise, how do you propose we
>> implement HTML and XRC loading from a resource egg? My original
>> proposition, which I now modify to meet your changes, was to use
>> wx.FileSystem to provide an "eggres" file source, which is very
>> similar to "http" and "ftp" file sources that are used for Internet
>> file access. In this case "eggres" just allows direct references to
>> files inside (an/a compressed) egg resources file, which I think you
>> need if you want to have websites, xml based user interfaces, or any
>> other type of files that refer to other files inside the resource.
> Actually I did document the use of the wx.FileSystem. I decided since
> it was a wxPython specific addition not to include it in the
> EggResourceManager API but instead make it part of the sub-class
> I18nManager. This seemed the best approach for now.
> From the I18nManager section of the proposal:
> 5. Adding a wx.FileSystem handler for retrieving resources
> defined in HTML or XRC
>> This example shows how easy it is to load a website index file
>> "index.html"" from domain "mydomain":
>> As we can see, there is no need to use any i18n specific API here...
> I am going to play with the syntax a bit for building the URL string.
> I think it can be simplified
> and made a little cleaner. But the ability to load resources in an
> HTML Pane or XRC is a great feature
> and will be leveraged for sure in Chandler.
I agree. I was not entirely satisfied how it was done in the prototype
either but I did not have enough time to improve the design at that time.
>> This example shows how you can set up an XRC resource directly above
>> the egg layer; we load a dialog that is described in
>> "myxrcdialog.xrc" in "mydomain" domain:
>> Again there is no need to use any i18n specific API here...
>> In both cases it is worth noting that index.html and myxrcdialog.xrc
>> are not direct filenames but instead resource name keys that are
>> routed to real filenames inside the eggs based on locale settings.
>> This means that we can localize an entire website or XRC resource in
>> a way that is transparent to the coder (see the examples above).
>> * It seems that you now agree with my original idea that we should
>> move some low-level implementation from i18n package to "Egg I18n
>> API". I think that this makes the design much more clear and easier
>> to manage in the future.
> That was always the intent. The underlying API had to be tweaked
> though. Your proposal if I remember correctly was to get rid or the
> I18nManager and MessageFactories and just use the egg API. My proposal
> is actually a bit different.
Yes this was one but not the only one proposal I presented (see my next
comment). Anyway the end result is very similar to what I had in mind
> Where ever there was redundency in the current I18nManger and the
> proposed EggResourceManager I
> moved the functionality to the EggResourceManager so it can be
> leverage by other Open Source Python
Yup this was my point all along.
>> Good work Brian, you get +1 from me. When do you expect the
>> implementation to be ready? I am anxious to complete my own i18n
>> threads, which require the "Egg I18n API" to be available in Chandler.
> I expect to have all the coding done by Friday, write the unit tests
> on Monday, then work with bear to get the changes folded in to our
> build system.
This is good news.
More information about the chandler-dev