Replacing module/handler

Vote:
 

Is there a way to replace a module or handler, just like entity types can be replaced using the EntityTypeOverride attribute?

#31702
Aug 10, 2009 9:44
Vote:
 

Could you elaborate on that? What do you want to achieve?

/Kristoffer

#31865
Aug 13, 2009 10:25
Vote:
 

What I want to do is basically to add versioning to the community document archive. What I thought I might do is to change the DocumentArchiveHandler / DocumentArchiveFactory to write files to a CMS versioning VPP.

BTW, how does the EntityTypeOverride really work? I created an override for the Document type, but at least in the EPiServerCommonEventArgs.Object delivered in the DocumentArchiveHandler events i still get a Document, not my derived class. Basically, if I just add a class to my assembly which just derives from Document (it doesn't add anything yet) and is marked with EntityTypeOverrideAttribute, shouldn't that class be used everywhere (possibly cast back to Document)?

#31866
Aug 13, 2009 10:30
Vote:
 

OK. Well, there's an issue inheriting the handlers since static methods in the handler cannot be overridden. What you could do to address this issue is to create a wrapping handler and let your code that accesses the document archive use this newly created handler instead. This new handler would also contain any code needed for your versioning.

In the events, you will still get a Document compatible type, but it actually is your derived type. That is, if you have configured the EntityProviderHandler to call your implementation of an EntityProvider for Document, and you return a type that inherit Document that you've chosen to call DocumentNextGen, you can cast the event argument to that type.

public class DocumentNextGen : Document { ... } 
void SomeMethod() {
   DocumentArchiveHandler.DocumentAdded += new EPiServerCommonEventHandler(DocumentArchiveHandler_DocumentAdded); 
} 
void DocumentArchiveHandler_DocumentAdded(string sender, EPiServerCommonEventArgs e) {
   DocumentNextGen d = e.Object as DocumentNextGen;
}

The EntityTypeOverrideAttribute is not actually a part in the system the allows replacing the implementing type. The EntityProvider-configuration is all that is strictly required in order to change the implementing type for Blog to a derived class of Blog instead. However, the EntityTypeOverrideAttribute is used when data is associated with a generic type, as in the Document Archive; both Document and DocumentArchive classes inherit from an abstract base class Content. Both the implementing classes share ID domain with the base class Content (there can be no Document or DocumentArchive with the same ID). Therefore, the EntityTypeOverride specifies that the ID domain is Content. In other words, you can request an instance of Content with ID 7 and get a return value that is either Document or DocumentArchive.

/Kristoffer

 

#31871
Edited, Aug 13, 2009 11:23
Vote:
 

I understand - so I still got a document because I thought the EntityTypeOverrideAttribute would do what the entity configuration is supposed to do. I suppose it is not a problem then that the supportedType configuration for the built-in entities is compiled into the DLL - I can just create a duplicate entry for, say, Document and "redirect" it to my new handler?

How will the built-in features where I can't control the handler call (the edit interface tab) handle my extension?

#31878
Aug 13, 2009 15:09
Vote:
 

Yes that's right. The built-in configuration is loaded as the defaults, and you may configure it in web.config, overwriting the defaults.

 The built-in features will not be aware of your extension and will continue to use the DocumentArchiveHandler.

/Kristoffer

#31885
Aug 13, 2009 16:51
This thread is locked and should be used for reference only. Please use the Legacy add-ons forum to open new discussions.