Re: Producing and consuming binary data

[Giedrius Graževičius <me...@inightmare.org>]

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
<da...@haywood-associates.co.uk> 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 <me...@inightmare.org> 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
>>

Re: Producing and consuming binary data

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Just to help mailing list cross-referencing - this thread continues 
here[1] as "Regarding ISIS-254".

[1] http://isis.markmail.org/message/qmuw25gd4rfapud7

On 2 Sep 2012 at 13:08, Dan Haywood wrote:

> On 2 September 2012 12:44, Giedrius Grazevicius <me...@inightmare.org> wrote:
> >
> > 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
> >
> > Thanks for taking this forward.  Had a quick review of those commits,
> looks like you're progressing fine.  (Nice to see for me, since I've given
> you zero guidance around the code base ;-)
> 
> 
> 
> > 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).
> >
> 
> The normal way to do this would be to define a facet for this (if there
> isn't a suitable one), and a corresponding facet factory, then registered
> into ProgrammingModelFacetsJava5.
> 
> 
> 
> >
> > 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?
> >
> 
> I think this might be a semi-known problem.  Jeroen and I were fixing a
> problem to do with Wicket and JDO on Friday evening, whereby a newly
> persisted object was then persisted twice if we immediately invoked an
> action on it.  The problem was that Wicket was serializing the state of the
> object into the page prior to the transaction actually executing (causing
> the adapter's state to move to transient to persistent).  My suspicion is
> that this is the same problem.
> 
> It's on the list to look at then...
> 
> Cheers
> Dan
> 

Re: Producing and consuming binary data

[Dan Haywood <da...@haywood-associates.co.uk>]

On 2 September 2012 12:44, Giedrius Graževičius <me...@inightmare.org> wrote:

>
> 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
>
> Thanks for taking this forward.  Had a quick review of those commits,
looks like you're progressing fine.  (Nice to see for me, since I've given
you zero guidance around the code base ;-)



> 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).
>

The normal way to do this would be to define a facet for this (if there
isn't a suitable one), and a corresponding facet factory, then registered
into ProgrammingModelFacetsJava5.



>
> 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?
>

I think this might be a semi-known problem.  Jeroen and I were fixing a
problem to do with Wicket and JDO on Friday evening, whereby a newly
persisted object was then persisted twice if we immediately invoked an
action on it.  The problem was that Wicket was serializing the state of the
object into the page prior to the transaction actually executing (causing
the adapter's state to move to transient to persistent).  My suspicion is
that this is the same problem.

It's on the list to look at then...

Cheers
Dan