: In this day and age, a custom update handler is almost never the right : > answer to a problem -- nor is a custom request handler that does updates : > (theose two things are actaully different) ... my advice is always to : > start by trying to impliment what you need as an UpdateRequestProcessor, : > and if that doesn't work out then refactor your code to be a Request : > Handler instead. : > : : e.g. benefits of UpdateRequestProcessor over custom update handler?
purely fro ma code reuse standpoint. Request Handler is really the coarsest, broadest, level of plugin you can implement. You can write one that does almost anything, but that requires you to do everything yourself. writing an UpdateRequestProcessor instead of a Request Handler lets you re-use your customiations with any Request Hanlder, and it's lets you mix and match the ordering w/ other Update Processors (instead of it being in your handler where you have to do all your special stuff before you call out to the processor chain) and makes it usable regardless of wether your documents are coming from the XmlUpdateRequestHandler or DIH, or whatever. -Hoss