On 21 August 2012 21:04, Giedrius Graževičius <[email protected]> wrote:
> Hello, > > Hi Giedrius ... and thanks, by the way, for your patch on the Wicket viewer (ISIS-239) - as you've probably seen, I've applied it. > Often there is a need to > > 1) produce some kind of a document (receipt, report, etc.) when a user > invokes an action > 2) store and retrieve files together with other business data > > As I understand, currently, Apache Isis does not support any of the > use cases described above. Issue list contains an item ISIS-172 that > talks about building documents, but does not mention a delivery > method. > I see these as rather separate from each other, so will discuss them separately. (1) ISIS-172 addresses this, using an approach similar to the way we do this on the big NO project in Ireland. The requirement there is to allow "the business" to develop communications in Word, but then use some sort of mail merge capability to inject in values from the domain object model. The JIRA issue describes the use of an XML input file; note also that some information is multi-valued, eg the "Payments" element which would correspond to a table. This probably points to a more sophisticated API than a simple mail merge (the latter of which can generally only merge in single scalar values such as a name or date). The Irish project is implemented in .NET, and Microsoft provide a rather good .NET API for manipulating OpenXml (.docx) files. When I went looking just now I couldn't find anything similar in Java-land, so I've just updated the JIRA to suggest that OpenDocument format (ODF / Apache OpenOffice) be considered instead. In terms of how a domain object would use this service, let me again explain how the Irish project works: we have a CommunicationTemplate domain object, which holds the .docx (or .odf) as a base 64 encoded string. The CommunicationTemplate acts as a factory for Communication objects, requiring that the appropriate XML be provided to it. The template then calls the DocumentBuilderService and gets back a mail-merged version; this is stored in the resultant Communication (again base 64 encoded). This sequence diagram [1] demonstrates this idea. (And I've updated the JIRA with all the above so we don't lose it). (2) one option for the storing of generated docs is to store them in domain objects that represent them. This is what CommunicationTemplate and Communication, described above, do. It does mean that the database grows pretty large of course, but RDBMS can handle these sorts of things perfectly well, and it saves having lots of complexity elsewhere. Using base 64 encoded strings also means that there's no new datatypes to be implemented. There is an argument, perhaps, for Isis to support a Blob type as well though, to be a little more space-efficient. I suspect you were considering some sort of "federated" object store, whereby the domain object holds some sort of URI link to a generated doc, that is itself served up via a file server? Of course, such a thing could be designed, but it would take more work to ensure that the viewers knew how to dereference such a URI, and it would certainly add complexity to the backend object store impls. > > Are there any plans to add ability for services to generate binary > data and for domain entities to store such data? As I noted above, there is an argument, perhaps, for Isis to support a Blob type as well though, to be a little more space-efficient. By all means raise a JIRA for this if you think it's warranted. > Or would it be > possible to contribute such functionality to the project? > > Contributions always welcome, of course! But before heading off on your own, I suggest we continue the discussion on this thread a little while, make sure we've come to a shared understanding as to what would be worth implementing, and how to do it. Many thanks, Dan > > Giedrius Graževičius > [1] http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgY3JlYXRlIENvbW11bmljYXRpb24KCkN1c3RvbWVyLT4rAA0NVGVtcGxhdGVSZXBvc2l0b3J5OiBsb29rdXAodAAUB0NvZGUpCgAXHy0tPi0AXAg6IABkDAAMCmJ1aWxkIHhtbABtIjoAgUAHKHhtbCkKAGcWLT4rRG9jdW1lbnRCdWlsZGVyU2VydmljZTogbWFpbE1lcmdlKHRoaXMub2RmAIFgCCwgAE0FACMWAIFABQB5Fm1lcmdlZE9kZgB0GQCCZA06IGluc3RhbnRpYXRlKAA0CQCBMhkAgi8PCg&s=qsd
