[Chandler-dev] Re: Request for Coments on Chandler Internationalization / Egg Integration Proposal

[Markku Mielityinen]

>>    * 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

OK.

>> This example shows how easy it is to load a website index file 
>> "index.html"" from domain "mydomain":
>> wx.html.HtmlWindow..LoadPage(u"mydomain#eggres:index.html")
>> 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:
>> wx.xrc.XmlResource(u"mydomain#eggres:myxrcdialog.xrc")
>> 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 
originally :)

> 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
> projects.

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.
>
> Thanks!
>
> 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.

Cheers,
    Markku