Can one only show the filters without the data?

[p38]

Is there a way to show only the filters set, without the corresponding list data?

If this can be done, is there a way I can filter another list based on the value of the current list filter.

I want to do a type of pseudo master detail, where the user chooses a filter value from the master list, and based on this, filter a detail list, all in the same screen?

Paul

 

[cheesegrits]

For only showing the filters, I guess you could do this with a custom list template, and chop out everything to do with actual list display, leaving just the filter display.

If this can be done, is there a way I can filter another list based on the value of the current list filter.

Do you literally mean "another" list, as in a different list? Or are you wanting to essentially have two levels of filtering, for the same list? Kind of like dynamic, user settable pre-filters? So the filters on the actual list display will also include those on the 'master' filters?

--hugh

 

[p38]

No, basically I want to have 2 lists on 1 page, the master list shows only the filters, and the detail list should filter records, based on the value of the "master" list.

Kind of pseudo master detail facility, without using your master-detail joins.

Paul

 

[cheesegrits]

Hmmmm.

I don't think that's going to be a trivial task. I can't even think of a way of doing it, off the top of my head.

-- hugh

 

[p38]

is there perhaps an "AfterFilterEvent" of some sorts?

If so, perhaps when this event is fired, I can get the filter value, then call a list plugin, passing the filter value?

Could this work?

 

[cheesegrits]

At the moment, no. Although that could be a useful event to add. My only worry would be that our filter handling is already massively complex, having to juggle pre-filters, element filters, URL filters and session filters. Adding a user driven phase to this would add a whole new dimension of potential for Filter Fubars, creating a support nightmare.

I might be prepared to look at adding a call to a list plugin hook as the last thing we do in the getFilters() method in the listfilters.php model. But if we did, we'd pretty much have to make it "use at your own risk", with little or nothing by way of support. We'd just hand you our $filters array, and let you modify it.

BTW, you could potentially do this by hand in a list template, although it would be cleaner for our code to call a plugin. If you look at the list template code, at default_filters.php, you could put some code in there to poke around in the $this->filters structure.

This might be the way to go for now, as we're pretty much done with adding new features to 3.0, so if we did at a list plugin hook for modifying filters, it would be much more likely to go in 3.1 than 3.0.

-- hugh

 

[rob]

The filters are already stored in the session, so you could write some PHP to grab those and then build your {fabrik view=list} plugin declaration from that.

The filters settings are stored using the following keys:

key = com_fabrik.list1_com_fabrik_1.filter.value
key = com_fabrik.list1_com_fabrik_1.filter.condition
key = com_fabrik.list1_com_fabrik_1.filter.join
key = com_fabrik.list1_com_fabrik_1.filter.no-filter-setup
key = com_fabrik.list1_com_fabrik_1.filter.hidden
key = com_fabrik.list1_com_fabrik_1.filter.key
key = com_fabrik.list1_com_fabrik_1.filter.search_type
key = com_fabrik.list1_com_fabrik_1.filter.match
key = com_fabrik.list1_com_fabrik_1.filter.full_words_only
key = com_fabrik.list1_com_fabrik_1.filter.eval
key = com_fabrik.list1_com_fabrik_1.filter.required
key = com_fabrik.list1_com_fabrik_1.filter.access
key = com_fabrik.list1_com_fabrik_1.filter.grouped_to_previous
key = com_fabrik.list1_com_fabrik_1.filter.label
key = com_fabrik.list1_com_fabrik_1.filter.elementid
key = com_fabrik.list1_com_fabrik_1.filter.raw

Most of which you wouldn't need to access, what I think you would need is the element id and the value.

// Get the list Model for list id 1
$listModel = JModel::getInstance('List', 'FabrikFEModel');
$listModel->setId(1);
 
$app = JFactory::getApplication();
 
// When stored in the session this lists filters are stored in this namespace:
$context =  'com_fabrik.list' . $listModel->getRenderContext() . '.filter';
 
// Get the element filter keys (which will be in the format `tablename`.`elementname)` which have filters attached to them:
$elements = $app->getUserState($context . '.key');
 
// Get the values
$values= $app->getUserState($context . '.value');
 
// Debug out what the filters are:
for ($i = 0; i < count($elements); i++) {
  echo $elements[$i] . ' filter value = ' . $values[$i];
}

 

[p38]

Brilliant Rob, thanks I can work with this.

Paul

 

[p38]

Is this code still Valid in J3.1?

I cant even get past

$listModel = JModel::getInstance('List', 'FabrikFEModel');

Paul

 

[rob]

Hi Paul
in Joomla3.x its now:

$listModel = JModelLegacy::getInstance('List', 'FabrikFEModel');

Don't ask why its Legacy if you did, "the mysteries of joomla" would be my answer!

 

[p38]

hi rob anything else changed?

Still no go......

If I put this code in Php_events, it still hangs the filter.

// Get the list Model for list id 1
$listModel = JModelLegacy::getInstance('List', 'FabrikFEModel');
$listModel->setId(9);
 
$app = JFactory::getApplication();
 
// When stored in the session this lists filters are stored in this namespace:
$context =  'com_fabrik.list' . $listModel->getRenderContext() . '.filter';
 
// Get the element filter keys (which will be in the format `tablename`.`elementname)` which have filters attached to them:
$elements = $app->getUserState($context . '.key');
 
// Get the values
$values= $app->getUserState($context . '.value');
 
// Debug out what the filters are:
for ($i = 0; i < count($elements); i++) {
  echo $elements[$i] . ' filter value = ' . $values[$i];
}

 

[rob]

hi Paul

Where are you using this?
What errors do you get reported by PHP?

thx
Rob