View Full Version : Filter Portlet Help

06-28-2007, 07:42 PM

I'm creating a Portal and using the Filter Portlet as in the guide.
It all works fine and I even put several filters in a Filter Panel.

But when I tried to put two Filter Portlets on the same page they both don't work at all.

If I minimize one of them, the other works well and vice-versa.

I saw the source code and I the Update button as OnClick the function "doForm()".
Both Portlets seem to put the same javascript code with the same names..
both portlets forms are named "Form" and the javascript that both create have se same function named "doForm".
I think this must be the problem.

Cant I use more then only one Filter Portlet ?
As anyone had this problem before ?

Does anyone thiink that maybe it is possible to remove the Update button from the portlet.. and create another portlet onyl with that button that is able to submit both Filter-Portlets ?

Thanks in advance to anyone that takes time in helping :D

Take care,

Tiago Cardoso

06-29-2007, 07:12 AM
So here was my problem:

I wanted to display two different Filter Portlets in the same Portal Page; each with it's own panel of filters inside.
Unfortunately, the default XLS that renders the Portlet writes a javacript responsible to make the submit on the 'Update..' button.
When having two different filter panels, to sets of this javascript are written, repeating vars and functions names.
The XSL took care of this by adding <xsl:value-of select="/filters/id" /> after each function or var name, or something that such be unique.
The nasty part is that on org.pentaho.ui.component.FilterPanel class this Id was completely hard coded. Like this: content.append("<filters xmlns:xf=\"http://www.w3.org/2002/xforms\"><id></id><title>....
So, a Id would never be different, it always be null .. empty.. nada..

I could just had rewrite take piece of code, but possible that's not a great solution for anyone not willing to have the source.
So I built an easier workaround.

On the XSL, after the tag <xsl:template match="filters"> write a parameter, like this:
<xsl:template match="filters">
<xsl: param name="myId" select="uid:currentTimeMillis()" xmlns:uid="java:java.lang.System"/>

Now, you have a UID. It's just the rendering time. Because the XSL takes time to render, the other XSL will ALWAYS have a different time in Mills.
Note that there are other ways to create a UID like using java.rmi.server.UID and java.rmi.dgc.VMID. But this is quicker, easier and probably more clear to understand.

Finally, replace every <xsl:value-of select="/filters/id" /> by <xsl:value-of select="$myId" /> .

It's done. Good luck ;)

06-29-2007, 11:39 AM

Thanks for taking care of that. It has been one of those nagging issues. I am creating a JIRA case to get that checked into the Platform.

Thanks again,

08-01-2007, 09:26 AM
Hi Tiago,

Thank you for working through this problem and suggesting a couple of possible solutions.

I took a slightly different approach than the one you ended up with. Instead of modifying the XSL, I modified the FilterPanelComponent, so that it always provides a unique id in the /filters/id element of the xml document. I also had to modify html-form-controls.xls so that in the generated javascript, the first parameter to calls to setXFormsValue() has the string "form" prepended to the /filters/id.

This should give us a unique id for each form generated for each filter.

This code was checked in on 8/1/07. It would be helpful if you can get a nightly build that was generated after this date, and re-test your code to confirm the fix.

thank you for your participation in the Community!