Hi Giedrius, just coming back to you on this.
I've raised ISIS-252 for the blob support; meanwhile ISIS-172 is already open for a document PDF service (as previously discussed). An Apache FOP-based service is definitely also a possibility; if you decide to raise a ticket on this, then please assign to the "Domain: Services" component. Thx Dan On 22 August 2012 18:49, Giedrius Graževičius <[email protected]> wrote: > 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 >
