views:

53

answers:

1

We have an application which will dynamically load some components from separate dlls. These components have a fixed name but we want localised names to be displayed to the user and so the names need to be localised.

The fact that the name needs to be localised is not a concern of the component itself, so we don't really want to pollute the model of the component with a property like DisplayName or LocalisedName, and have the resources for the component live in the dll for the component. But as these components are pluggable we can't have the the resource for the display name live in the application, as then when we added new components, the resources for the application would need to be updated, defeating the point of making the components pluggable.

Is there are common solution to this issue? The possible solutions we could see were:

1\ Have a property called display name which the gui code calls to display the names. This works ok, with the resources existing in the same dll as (or satellite dlls of) the assembly that contains the component. But this seems to pollute the model with information that the component should not care about.

2\ Have the app with the GUI look up the resources for the named component from its own resource files. This fails because the app needs to have its resources updated when new assemblies containing new dynamically loaded components are added.

3\ Have the app look in the resources of the assembly the component came from for the localised name of the component. This seems good as the localised name exists in the assembly for the component so is distributed with it, but the app with the presentation layer instigates the lookup of the localised string from the components dll, so the component does not need to know anything about the localisation and so its model is not polluted.

Is option 3 possible? Is there some other option we have not considered?

cheers...

A: 

Option 3 is what I would do, and I think it's possible. If you know the name of the plugin and can instantiate a class using reflection. You then query that class for a LocalizedName, which the plugin would fetch from its resource assembly. I presume you understand how satellite resource assemblies work.

Is there something specific about #3 that does not work for you? If you specify what doesn't I might be able to help...

psychotik
I played around a bit and ended up with something that works. I have outlined my proposed solution in another question. http://stackoverflow.com/questions/1559716/is-this-a-good-solution-for-localisation-of-pluggable-componentsany feedback would be appreciated.
Sam Holder
see my comments there...
psychotik