Hi Martin, I have just created a ticket: https://issues.apache.org/jira/browse/WICKET-5581 Thanks for taking it into consideration.
Overriding #getVariation() works well but it is, as you say, a workaround. I look forward to having CachingRes​ourceStrea​mLocator improved. Thanks again, Fabio On Tue, May 6, 2014 at 12:51 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > Hi, > > Please file a ticket at https://issues.apache.org/jira/browse/WICKET and > we > will improve it. > As a workaround you can override #getVariation() for the pages and return > "html" and "fo" respectively. > > Martin Grigorov > Wicket Training and Consulting > > > On Tue, May 6, 2014 at 11:39 AM, Fabio Fioretti < > windom.macroso...@gmail.com > > wrote: > > > Hi all, > > > > I have a Wicket 6 application that integrates with Apache FOP in a way > > that, by overriding Page's getMarkupType(), I can have a component render > > its .fo markup (to generate a PDF) instead of the usual html, depending > on > > whether it is added to a Page with the fo MarkupType or the standard html > > one. > > > > This means my typical Panel has two markup files, an html one and a fo > one: > > Panel.fo and Panel.html. > > > > Now, the default CashingResourceStreamLocator makes use of > > ResourceReference#Key for the cache. That Key completely ignores the > > extension of the file or, better, assumes it is part of the name, while > for > > markup files this is apparently not the case. Basically, Panel.html and > > Panel.fo have the same Key, the name of which is simply "Panel". > > > > Therefore, when a Panel is first rendered in html, its html markup > > reference is cached and there is no way to make it render again in fo, > > because the cache will always return the html markup reference. > > > > The solution is not dramatic but makes me feel uncomfortable: I had to > > write a custom CashingResourceStreamLocator clone, using a custom Key > that > > is basically a ResourceReference#Key with an added "extension" property. > > > > What am I missing here? > > > > Thanks very much for you help and keep up the excellent work, > > Fabio Fioretti > > >
