Two quick responses since I'm still working on the apachecon presentation:
- I'm happy for this to be a part of views and I hope after apachecon I'll know how to use them for this purpose. - I agree that the filter could and perhaps should be configured as part of the configuration. > ...and content writer != admin (site.xml) - I do not agree that editing site.xml is admin work as Thorsten seems to suggest since it is the only way a user can make Forrest show his page. - And since I (with the content writer hat) usually make the decisions about which file to show in which menu and what filter should be applied to it (e.g. show the directors version of Shakespeare in my 'Directors resources' menu while the full version is in the 'Popular Dramas') I (user) need a way simply apply a filter to a given resource. To determine which filters to apply to which resources (by the list of patterns in the plugin config that Ross suggested) does not seem an ideal solution to me as it requires an understanding of patterns that users don't usually have and also makes it much harder to see what will actually the outcome of a certain site.xml (because you have to also look at the filter patterns in the plugin (and apply that knowledge to site) to know what will actually show. Very difficult and not easy to maintain. I understand the objective not to extend site-grammar for every new plugin (and share it), but I'd raise the question if it wouldn't be a good idea to consider it at least for some basic operations like filtering, pdf-aggregation and ... And if that is not agreeable, to find some other way of keeping the selection of a given filter closely with the site-element. -- Ferdinand Soethe
