* 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
