Thanks for the reply. I considered changing the source code and
recompiling JMesa, but I didn't want to go through the hoops of
getting the dependencies straightened out (I don't use Maven). Plus
then I would be on my own fork and couldn't upgrade easily if / when a
new release comes out.
What I did instead was to make 3 subclasses, one each for
CsvViewExporter (to change the suffix), TableFacade (to instantiate my
new CsvViewExporter) and TableModel (to use my new TableFacade). It
was not exactly elegant, but it got the job done. So in my
controller, I instantiate the custom MyTableFacade first, then pass
that in the constructor to my custom MyTableModel class (calling the
protected setTableFacade method from the constructor). I think
another regular TableFacade also gets created and then immediately
replaced by my custom one.
On Oct 19, 4:39 pm, Jeff Johnston <
jeff.johnston...@gmail.com> wrote:
> This is a use case that needs to be addressed. Honestly it just has not come
> up like I expected it would and so I have not done the steps to expose it.
> Your right though that with JMesa what you would typically do is find the
> right class to extend and plug it in. But there is nothing difficult about
> doing that as we would just need to make it easy to plug in the ViewExporter
> the same way that we allow everything else to be plugged in.
>
> That said if you were really motivated you could hack it in there a few
> ways...but none of which would be all that great given the new TableModel
> abstraction. Here is a link to the way you could have done it when we worked
> directly with the TableFacade.
>
>
http://code.google.com/p/jmesa/wiki/ManualTableExport
>
> But really what I would do is either change the CsvViewExporter's
> getExtensionName() and recompile the project....or, better yet improve the
> API so that the we can plug in ViewExporter so that it works like everything
> else. If you wanted to do that feel free to email me at
>
jeff.johnston...@gmail.com and I can explain how I would go about doing