Hi, On Thu, 2006-04-13 at 02:23 +0200, Steven Wittens wrote:
This was an interesting read, and I think replicates the system that is currently here. I think that the filter system is great, but if it is context based, we can have a much clean UI and will allow developers to use filters in more places without adding unnecessary information to other parts of the system.
eg. If I was to make a E-Commerce Transaction filter to allow adding of additional information on emails that are sent out, which the filter system would be perfect for, would just be additional junk that a user doesn't need to see when creating creating a node.
The filter system has always been context agnostic: it takes text and marks it up. This is intentional, mostly because it ensures it only deals with actual markup and styling, and not features.
I think you have misunderstood me. When I am talking about a context I am talking about where it is coming from. I want to be able to is have a filter that is only applied to certain types of content. And this will be at the filter level and not the filter form(?) level. So I could have a group of filters which make up the "filtered HTML", but depending on what it is filtering not all of them are being executed. So I may have filters which only apply to a block. It will still be included into the "filtered HTML" filter the user see's but will not be displayed in the filter help or executed if the content is not a block. Given this people can develop very targeted filters which are only used for a single purpose, such as the what I want to use it for and that is to add transaction information to the emails by using the filter. Also with this I would be adding a payload of additional data. So when filtering node content, the node will be past to all the filters so they don't have to work out the node again, which will save on cpu.
Implementing contextual filters goes well beyond passing in a $node parameter. What happens for example when you edit a node? How is the filter cache keyed, and do we wipe it selectively? Do we provide contexts for other things than nodes too?
I was thinking that the data that is past would just be an array of data that you want the filters to have access to. In the case of the php filter the array would just be extract()'ed and these would turn into local vars. function drupal_eval($code, $vars = null) { if ($vars) extract($vars); ob_start(); print eval('?>'. $code); $output = ob_get_contents(); ob_end_clean(); return $output; }
You can already modify node content using nodeapi before viewing. The only downside is you don't get it cached through the filter cache.
I am not really wanting this for changing node content, but for filtering content outside in other areas like blocks, and others. Filtering nodes is fine, but filtering content which are not nodes is a little lacking, and being able make certain filters context sensitive in that they are only used for certain types of content would make it much more powerful. Gordon.