A general way of using [ExportMetadata("Order", ...)]

[JelleVM]

ATF currently provides the option to adjust the order in which classes are initialised, using [ExportMetadata("Order", ...)]. Though I try to use this as little as possible as it makes components less generic, I've come to see that sometimes it's unavoidable.

It would be very useful if there were some API that made this order a bit more generic, and if it were used in the first place in the components. I haven't quite figured out yet how this would look, maybe you guys have some idea on this. Maybe something like and enum ImportOrder and then putting this on the components/services on which order matters.

Also, maybe the default for this value shouldn't be INT_MAX. For example, it is extremely useful to have Composer being initialised as early as possible, but I currently have no way of ensuring it's initialised before my other components. That is, not without touching the ATF framework myself at least.

Hope this makes sense.

[abeckus]

Thanks for the suggestion, one of us will look into this.

Alan

[abeckus]

At point the [ExportMetadata("Order", ...)] is not used for controlling initialization order. It is declared in Atf.Wpf section which is work in progress. Generally MEF does a pretty good job of negating the need to explicit control the order. In some cases IPartImportsSatisfiedNotification can be used for component that obtain dependencies via [Import] instead of [ImportingConstructor]

Thanks Alan

[Ron2]

Hi Jelle,

That usage of ExportMetadataAttribute in ATF was inadvertent. One of our clients uses it, but we did not copy over the mechanism that looks at that attribute. The sorting mechanism would be very similar to this post: http://stackoverflow.com/questions/1770297/how-does-mef-determine-the-order-of-its-imports

I don’t think we should use this ExportMetadataAttribute in ATF in this way. There are a variety of ways to control the initialization order that are more obvious and lower-maintenance than having a numerical explicit order on the component.

• You can implement MEF’s IPartImportsSatisfiedNotification, which has the OnImportsSatisfied() method. This method will get called by MEF when all of the imports have been satisfied. • Your component’s IInitializable.Initialize() method will be called after composition, and so all of the objects in the TypeCatalog will have been created, and then you can do further initialization. • You can have lazy imports, to get around a circular dependency. For example: [ImportMany] private IEnumerable<Lazy<IDocumentClient>> m_documentClients = null; • You can override AtfApp’s OnCompositionBeginning() to acquire certain types of objects from your CompositionContainer, to make sure that certain objects are initialized first. • You can override AtfApp’s OnCompositionComplete() to do last-minute initialization of certain objects.

Can you please try some of the above ways? If these are not sufficient, then we can try to support ExportMetadataAttribute with an “Order” property and an integer value. Otherwise, I’d like to remove that one usage.

--Ron

[JelleVM]

Hi Ron and Alan,

Thanks for your answers. I think one of those solutions might be the right one, but I need to delve into it a bit more.

Let me outline the problem, to give a bit more context. I am using the CommandServiceExtension, which is extremely useful for binding to commands directly from XAML. The only problem is that this XAML is part of an import. In the CommandServiceExtension class, it is required that the Composer and the CommandService be imported and ready, and to actually use it, your command has to be imported already too. The nasty thing about a MarkupExtension is that ProvideValue() is only ever called once and then never more, so if any of the aforementioned required imports haven't happened yet, the command binding will be invalid forever. Hence my need for the import order.

I think forcing those to be loaded OnCompositionBeginning() might work, to it'd be a hacky way. IPartImportsSatisfiedNotification isn't going to help here, methinks. Perhaps I can make all my XAML Lazy loads indeed, but I'd have to check if my application allows that.

All the best! Jelle