Hi Dan. thank you for your answers.
> (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. This is exactly of what I had in mind. I'm a big fan of storing all the data in one place (usually meaning some kind of DBMS). The BLOB type would be perfect. It's just that in such cases if it's an attribute of a domain object it should be lazily loaded. I'm not sure if this is already covered in some way in Isis storage infrastructure (as all properties and one-to-one relations are likely to be fetched eagerly). > 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. This was the intent of my e-mail. What I envision that these blob typed attributes would be handled as files by the viewers. That is the file upload box would be presented and if there is some data present it would be possible to download it as a file. The implementation for this seems to be pretty straightforward, though all the views need to be updated to support this (an ability to disable file reupload is a must, as some systems, like document/record management, don't allow modifying the data after it has been created). There would also be some type of an action that would return produced documents directly to the user. For example user wants report for April, he enters the date and gets the report as a direct download. (In my simple POC implementation I apply a Facet to all the actions starting with "produce" and expect those actions to return an InputStream, though a more efficient solution would be to pass an OutputStream to directly write the data). So from what I see 1) all object sores need to be updated to support the lazy loading of blobs 2) a way of presenting those types should be added to the viewers 3) a way of allowing to directly return binary content from an action would be added to the viewers (This is optional as files can be stored in domain objects. It's fine in most cases. However, my argument pro direct downloads is that not all the documents need to be stored, also if a document (report, template) can be generated quickly it's much more convenient for the user to just get it directly. It also simplifies the case of external integrations as instead of two calls: generate and retrieve, you only have to do one generate-and-retrieve). Despite the effort associated I consider this a must-have feature, as most enterprise systems I have seen/worked on deal with documents in one way or another. As for an out of the box document generation solution, I was thinking about Apache FOP, as solution like Jasper Reports is probably not "free enough" for Apache projects. They also have ODF support in their wish list, maybe someone is already working on this as ODF Toolkit (and the whole OpenOffice) is now an Apache project. Giedrius
