[development] check_markup() question

[Gordon Heydon]

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.