Hi, yes, I fully agree that it violates the DDD idea, but on the other hand, I don't see a point in implementing part of the system as a separate servlet which doesn't have access to the underlying Isis facilities.
We need access to other services to implement business logic e.g. depending on the size of the upload or on the file signature (magic numbers). In most cases, we just have to read the InputStream of the servlet and write it out to a file, which is much more memory-efficient than reading the whole file as a base64 string into memory, decoding it, and then calling an action with the Blob. I'm not opposed to programming some facility (an Isis module?) which streams the content of the request to a file - or multiple files in case of a multipart request - and _then_ calls an appropriately annotated action with the metadata of the files/request, but it would help a lot to have such a facility inside Isis instead of writing a separate servlet and manually integrating its deployment and the calling of domain actions etc. Cheers Kambiz On 2016-08-03 18:53 CEST, Willie Loyd Tandingan <[email protected]> wrote: > Hi Kambiz, > > We had a requirement similar to yours. The problem with injecting > HttpServletRequest to domain services is that it kind of violates the DDD's > hexagonal architecture by letting viewer implementation leak into the > domain layer. > > The specific requirement that we had was to be able to pre-upload files > before submitting an action. We developed a custom blob that stores an id > instead of the actual data, a service layer that manages a blob storage > abstracting and running on top of jclouds (we plan to be able to support > other types of storage aside from file system), and a file service that > manages the state of "transient files" (files that were pre-uploaded or > that are returned from actions as result of export functions, etc.) as well > as means to persist them (i.e. move them to another > container/bucket/folder). > > We then developed a custom servlet that handles download and upload and > integrate them with isis. This enabled us to implement features like forced > attachment content disposition, or on-demand image resizing. > > Should you have other ideas or questions, feel free to ask. > > > Best regards, > Willie > On Thu, 4 Aug 2016 at 12:37 AM Kambiz Darabi <[email protected]> wrote: > >> Hi, >> >> I have to implement a legacy file upload service for a customer. Files >> of up to some hundred megabytes are uploaded to a service over HTTP POST >> and a unique ID is returned which can be used to refer to that file, add >> metadata to it etc. >> >> Using Blobs is not viable as parsing of the base64 encoded binary data >> and the allocation of multiple strings during request processing >> increases both the time and space requirements. >> >> Ideally, I would be able to create an action on one of my domain >> services which has a HttpServletRequest argument and take care of >> reading the binary data and writing them to the file system. >> >> I have played around with the request processing part of the >> restfulobjects viewer/server and managed to get the request/response >> objects through. >> >> I know that this is a real edge case, but I think that it is important >> to have solutions for edge cases, too, if Isis is to be used as a >> general purpose platform. >> >> Could some committers please review the changes and maybe propose a >> cleaner way of implementing this? >> >> >> https://github.com/m-creations/isis/commit/aa3b16a5cf463466f5abadbcc8cc73f16857a628 >> >> Thanks >> >> >> Kambiz >> >>
