Than you, Dan. Currently looking into the binary support. I've added simple byte[] support in a Wicket viewer (treats the property as a file that can be uploaded). Changes can be seen here: https://github.com/INightmare/apache-isis/commits/ISIS-254
Now to figure out a way to make Wicket treat such property a bit differently than other values (that is prevent it from accessing it, unless user specifically requested it). Also: When trying to edit newly created object in Wicket viewer with DataNucleus as ObjectStore, the following exception occurs: http://pastebin.com/4tCiCqiZ Am I doing something wrong or is this a known problem? On Thu, Aug 30, 2012 at 2:12 PM, Dan Haywood <[email protected]> wrote: > 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 >>
