458302 - [silme] should be possible to parse only selected files in l10nPackage

Status: NEW

(Localization Infrastructure and Tools :: Silme, defect)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

In many cases you load l10nPackage but you don't really need all objects to be parsed.

For example in compare-locales you want to load only objects that exist in both packages.
For example in GUI app you load l10nPackage to list objects but you can parse the object which user selects instead of loading all of them and keeping them in memory for all the time.

In many cases user/script will load whole ab-CD package but will need only 50% or less objects parsed.

In my vision it would look like this:

# I want to load all objects as Object
# and not load sources since I don't need them
l10nPackage = silme.io.Manager.get('file').getL10nPackage(path, object_type='object', source=False)
(...)
l10nPackage.getElement('toolkit/global/ble.dtd').parse()
object = l10nPackage.getElement('toolkit/global/ble.dtd')
print object # prints l10nObject parsed properly

or:

l10nPackage.parseToL10nObject('toolkit/global/ble.dtd')
l10nObject = l10nPackage.getElement('toolkit/global/ble.dtd')

or something like this. Former API would make it possible for Object to parse itself to L10nObject even after being received from l10nPackage.

What do you think?

p.s. of course *normal* behavior will give you io.getL10nPackage(path) - with objects loaded, and source=True will also load sources.

Comment 1

[Axel Hecht [:Pike]]

Two things:

First, I parse missing files in my library, because I want to get a total count of missing localizable entities.

That might not be an issue for all use cases of Silme.

Second, it sounds like you really want to do on-demand parsing of files. Doing those late and on-demand sounds like a much cleaner API than having to figure that question out up front, and having no chance to reconsider. Something like a getter for details or putting those into a function and and caching the results sounds like a good path. And initial constructor argument on the other hand isn't something that I'd like to think about.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

good point.

I didn't think about this, but getter sounds to be a nice and clean solution.

I just wanted to ask, do you really think that giving an argument is a wrong idea?

Currently there are two options: getL10nPackage(path, objectType='entityList') or objectType='l10nObject'. Adding third - objectType='object' would give a coder choice on what he really wants to load in l10nPackage.

As far as I understand what you propose is that nothing is loaded in getL10nPackage and getter runs parser, right?
I think it would be a problem in case you want to load l10nPackage, modify one l10nObject and save the package to other location.

Regarding stats - yea, but that should do with entityList instead of full l10nObject.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

it's not blocking 1.0 release, and it should be resolved together with bug 464107

Comment 4

[Francesco Lodolo [:flod]]

Moving Silme bugs to its component.

[Mass change filter: silme-move]