Show dynamically generated html files which contains relative paths on dema

Hi guys,
I have an external quality control tool which generates a folder containing a quality report.
The folder contains:

  • An html file (the report)
  • an icon folder
  • an image folder

the html file contains relative paths to the icon and image folder. The icon folder has always the same images. Unfortunately, it does not hold for the image folder.
Clients should be able to generate the reports and visualize them via a liferay portlet. And generating the reports is not an issue but what about visualization?
I was hoping I could achieve it with a small vaadin portlet.
Is there a nice approach to visualize the file including the icons and images?
Doing it with a
BrowserFrame
and
FileResource
,
ThemeResource
or
ExternalResource
does not show the icons nor the images.
Is there some kind of working directory from which the html could access the icons and images? Or is there a more elegant solution I did not think of?

Cheers,
David

I have a similar problem I am trying to solve. I have been using a Label to display the HTML, but it cannot show icons or images any better than the BrowserFrame. I ended up preprocessing the html when the user clicks on the file (in a tree), looking for all img src components (java regex), copying the image files into a directory under my application, and rewriting my img src elements to point there instead. Massive pain, but it worked. I ran into trouble with internal links ( href=“#foo”) since they did not relocate. The BrowserFrame handles those, but it doesn’t behave like Label in other respects, so I am still struggling with my implementation.

Another option would be a custom RequestHandler to serve the files.

If using that approach, make very sure that any file you are serving comes from the report and not from outside it on the disk - there are numerous ways for the client to send relative paths to try to escape the report and read files in the WAR or the file system, not just the trivial “…/”.

Thanks for the reply Henri.

After reading about RequestHandlers in BoV, this appears to be, for my purposes, a straight replacement for the UriFragmentChangedListener I currently use. My current problem is that I can’t get the rewritten urls that the user clicks within the BrowserFrame component to be “heard” by the UriFragmentChangedListener living in my UI component. Will a RequestHandler be able to detect this? I guess my question is “Is the RequestHandler mechanism a lower-level interface that can respond in more situations than a UriFragmentChangedListener ?”

As for security, I get what you are saying, and am able to check the files being rquested via the URI to ensure that I have received a valid request.

So before I start building a RequestHandler, do you believe it will help with my problem with the BrowserFrame component, or is there a better way?

–PK

A RequestHandler can work with the parts of the request that are normally sent to the server by a browser (what comes before the “#”) whereas what comes after it is the fragment. Fragment changes do not force the browser to reload the page, which is why they are used in application internal navigation etc. The two are handled separately - the first part of the path with a RequestHandler and the fragment using Page.addUriFragmentChangedListener() for the Vaadin application page itself, where the widgetset explicitly sends the new fragment to the server.

OK, I replaced my uriFragmentListener with a RequestHandler, and it makes it through from the BrowserFrame’s rewritten URLs. It’s good to know the difference in how these two url markup techniques, for lack of a better term, are handled. Thanks for that Henri – RequestHandler is a better solution for me.

On to use of the BrowserFrame component itself, many others have noted that when you try to reuse a BrowserFrame (in my case a user would click on another html file in thier tree) it will not display the output of the second resource. Calling setSource(null) followed by setSource(new_file) does not work. Swimming up through the source code a few levels makes me think that since setSource is really working with a map, maybe, since my temp file name is not changing, either nothing is happening, or since the key (file name) has not changed, the BrowserFrame does not know about the change to the actual contents. No matter…

I finally realized that for me the solution is simple. I no longer need the previous BrowserFrame at all, so I just create a new one and drop it in my Panel component. That works great. The user clicks on several html files in the tree and they each show up properly on the right hand side.

So now, with my urls rewritten to point back to my application with a parameter, I click on a rewritten url in the BrowserFrame, and my RequestHandler gets the parameter off of the VaadinRequest, and I think I am in business…

With the url click just mentioned, I go back through the same code as if the user had clicked on a tree item, using the new file name. I validated that the file exists (my html reports have proper relative urls in the first place), and stepped through with the debugger. I am in the exact same place in my code, but when I create the new BrowserFrame, it fails to show up.

I’m confused again!

–PK