That property builds the resource file name by appending its ID to the path.

I'm not sure about the ID approach, since appart from regular module loading, this won't work with specific IDs.

For instance, this does not work with User Controls, nor does it work with module controls in Inventua's Shadow module or I guess any module of that kind.

Personaly, I found it useful to define a base control with the following properties:

Public Property MyFileName() As String

Get

If Me._MyFileName = "" Then

Me.MyFileName = Me.GetType.Name.Replace("_ascx", ".ascx")

End If

Return Me._MyFileName

End Get

Set(ByVal Value As String)

Me._MyFileName = Value

End Set

End Property

Public Property LocalResourceFile() As String

Get

If Me._localResourceFile = "" Then

Me._localResourceFile = DotNetNuke.Services.Localization.Localization.GetResourceFile(Me, Me.MyFileName)

End If

Return Me._localResourceFile

End Get

Set(ByVal Value As String)

End Set

End Property

I've read that GetType is pretty quick unlike some other Reflexion methods so that could be an alternative, what do you think?

My point is not really about the efficiency of that property on regular skin loading use. I never had any problem in that case neither.

It was more on the fact that maybe we could avoid having that property from PortalModuleBase rely on the InjectModule method from the skin.vb.

This is just that if relying on something generic as suggested, we could have both PortalModuleBase and UserControlBase expose that same property as somthing generic and independant from the control's life cycle (and maybe have the first one inherit the second one)

You can argue that PortalModuleBase controls are tied to the skin.vb so it is not a problem, but I can see points for developers to be willing to shortcut that, such as for Inventua's Shadow Module or some other multi module containers module.

If we can avoid that dependency, shouldn't we do so?

Furthermore, the MyFileName attribute is usually hard coded for user controls. This is to my opinion the thing that both module and user base controls could provide generically without the need to rely on the control's ID.

Finally it might be time to abstract a little more the base classes by adding some more standard functionalities (and as said above, with a richer UserControlBase, PortalModuleBase could inherit it bringing some more coherence) . It is once again to my opinion one of the things DNN code lacks.
I think this also true for entity classes, which don't rely on any base class or interface. Having a base EntityInfo class base on the CSLA.Net framework could be a suggestion for bringing more power to the Business Layer. Bringing similarly a more powerful base class to the presentation layer is what this post is about.