On 26 November 2015 at 06:18, Kevin Meyer <[email protected]> wrote:
>
> By the way, the existing service action already took a Report as a
> parameter - but the Clob return solves this error and now works.
>
>
Yes, I saw that... but when rendered as a contributed action it basically
is a no-arg.
That is,
@DomainService
public class Html implements ReportPrinter {
public Object printAsHtml(Report report){ ... }
}
in the metamodel that is built is equivalent to you having written instead:
public class Report {
public Object printAsHtml() { ... }
}
ie, a no-arg.
If you changed the contributing service to:
@DomainService
public class Html implements ReportPrinter {
public Object printAsHtml(Report report, String fileName){ ... }
}
then that would correspond to:
public class Report {
public Object printAsHtml(String fileName) { ... }
}
Hope that makes more sense.
Incidentally, rather than using a contributed service, for this requirement
I suggest using the new @Mixin feature. Thus:
@Mixin
public class Report_printAsHtml {
private final Report report;
public Report_printAsHtml(Report report) { this.report = report; }
public Clob $$(String fileName) { ... }
}
The "$$" is a reserved word, it means "infer the action name from the class
name of the mix in".
All the usual disable, validate etc can live in here, so the mixin nicely
encapsulates all this stuff. It also makes it easier to rationalize about
the relationship about what the action "needs to know" about the object
that it is mixed into; ie one can an interface to make this relationship,
eg:
@Mixin
public class Htmlable_printAsHtml {
private final Htmlable htmlable;
public Htmlable_printAsHtml(Htmlable htmlable) { this.htmlable =
htmlable; }
public Clob $$(String fileName) { ... }
}
and
public class Report implements Htmlable { ... }
So the mixin is really a trait. This is basically the Reenskaug and
Coplien's DCI pattern, I believe. I really like them, YMMV.
HTH
Dan
> I will look into the docx module.
>
> Kind regards,
> Kevin
>
> On Thu, November 26, 2015 01:31, Dan Haywood wrote:
> >> On 24 November 2015 at 19:02, Kevin Meyer <[email protected]> wrote:
> >>
> >>
> >>> I've added the project to github on [1]. Sorry - I've not put much
> >>> effort into consolidating the menu/service actions, most of them are
> >>> visible even when not appropriate.
> >>>
> >>> I've implemented the "convert and send as file" as a service at [2].
> >>>
> >>>
> >>> For convenience, I've created a fixture script.
> >>> After loading the fixture, go to "Reports" and use "Find First" to get
> >>> a report[3], then choose "Print as Html" - which fails with the
> >>> exception. "Print As Latex" just returns a String.
> >>>
> >>>
> >>>
> > OK, so this is pretty obscure, but the good news is that there are easy
> > workarounds to the problem.
> >
> > This code fails:
> >
> >
> > public Object download() { return new Clob(...); }
> >
> > but this code will work:
> >
> > public Clob download() { return new Clob(...); }
> >
> > (ie specify Clob not Object as return type)
> >
> >
> > and so will:
> >
> > public Object download(String filename) { return new Clob(...); }
> >
> >
> > (ie take at least 1 argument).
> >
> >
> >
> > ~~~~
> > The issue is down to the way in which we set up the Wicket viewer's Ajax
> > handlers; downloadable objects with no-args have to be dealt with in a
> > certain way, and we look at the action signature to try to guess.
> >
> > I've raised a ticket [6] to see if we can support all the cases, but I
> > don't see it as a high priority to fix.
> >
> >
> > Thx
> > Dan
> >
> >
> > PS: probably tangential to what you are working on, but the isisaddons
> > has a docx module [7] for mail merges. And Jeroen experimented with
> > xdocreport [8], which looks simpler still; we will probably make a very
> > minimal module around that, too.
> >
> >
> >
> > [6] https://issues.apache.org/jira/browse/ISIS-1264
> > [7] https://github.com/isisaddons/isis-module-docx
> > [8] https://github.com/opensagres/xdocreport
> >
> >
> >
>
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
>
