Save vs Publish
Save vs Publish
The IDocumentStorage interface does not contain a method for PublishDocument - I'm wondering if there is anyway to tap into the Publish functionality? It seems a little awkward that the only time I get control to save the document image is after the user publishes/previews and saves the document or saves the order. I could imagine that publishing a document caches the data elements of the document locally and the user would have an opportunity to 'rollback' those changes when they chose not to save the order.
-
Mark McKenna
Re: Save vs Publish
Published documents (attachments), under our default print job handler implementation, can be thought of as a collection of pointers to physical documents that are themselves stored somewhere outside of our database. The "somewhere" is where the IDocumentStorage interface comes into play. When you select a document and click Publish, all the publish handler really does is create an attachment object that is associated with the Order to represent a "pointer" to the actual PDF file that was generated. Since it's just another object belonging to the Order (like any Loan or Buyer), a pointer object saves and loads as part of the Order. If the Order is not saved after publishing, the attachments are lost. When the Order is saved, we route a call through the IDocumentStorage.SaveDocument method to give your implementation class an opportunity to actually go do something with the file (like save it to disk or feed it into a DMS, etc.). That's why these 2 operations have to occur in parallel (we save the pointer record at the same time that the document is physically stored somewhere).
Most of the publishing internals are not exposed to the public. To make the Publish button behave differently, like storing the file image somewhere immediately independent of our Order saving/loading, you would probably want to consider replacing our Publish print job handler with your own (or inject your own to execute before ours, as described in my response to your other post a few minutes ago). Be aware, however, that abandoning our default handler would mean that published documents are no longer associated in our system with the Order, and they are not treated as attachments. Further, the IDocumentStorage interface would be meaningless since that mechanism works specifically with our default Publish handler. Select would lose all knowledge of the published documents.
At the end of the day, you have 2 options with respect to customizing Publish: (1) Use our default print job handler and implement your own IDocumentStorage class, or (2) abandon our default print job handler and write your own with the understanding that we maintain no associations with the Order at that point.
I hope this answered your question.
Most of the publishing internals are not exposed to the public. To make the Publish button behave differently, like storing the file image somewhere immediately independent of our Order saving/loading, you would probably want to consider replacing our Publish print job handler with your own (or inject your own to execute before ours, as described in my response to your other post a few minutes ago). Be aware, however, that abandoning our default handler would mean that published documents are no longer associated in our system with the Order, and they are not treated as attachments. Further, the IDocumentStorage interface would be meaningless since that mechanism works specifically with our default Publish handler. Select would lose all knowledge of the published documents.
At the end of the day, you have 2 options with respect to customizing Publish: (1) Use our default print job handler and implement your own IDocumentStorage class, or (2) abandon our default print job handler and write your own with the understanding that we maintain no associations with the Order at that point.
I hope this answered your question.