On 4/11/06, Bèr Kessels <ber@webschuur.com> wrote:

Op maandag 10 april 2006 01:40, schreef Gordon Heydon:

...

Also is it possible to have a filter that is allowed only in certain situations as I would like to turn all the ecommerce emails into filtered fields, but this does not really relate to a node at all.

You may want to look at blocks. They are not node (ugh) and still use the filters.

Also have a look at views, which uses filters for a number of custom text fields, such as "view header" and "view footer".

Hi, On Tue, 2006-04-11 at 09:53 +0200, Bèr Kessels wrote:

Op maandag 10 april 2006 01:40, schreef Gordon Heydon:

...

Also is it possible to have a filter that is allowed only in certain situations as I would like to turn all the ecommerce emails into filtered fields, but this does not really relate to a node at all.

You may want to look at blocks. They are not node (ugh) and still use the filters.

I have taken a look at this, and it was what I expected. check_markup() is good if you want to call it in total isolation, ie so what is contained within the content don't really need to know where it is being called from. In the case of a node with php content you can generally work out what the node is and do a node load to get the data. By this is really a little inefficient, because before calling the check_markup() from node_prepare() we already have the node object, so it would be nice if you can have the $node as a local variable so that you can use it. Also with the filters it would be nice if they can be more content type oriented. I would like to be able to classify filters so that they only get used on certain types of content. So the current filters would be considered a global filters and would appear on everything, but for E-Commerce I could create a transaction filter class and this will only be display on the emails that are sent from ecommerce, and not in other areas like nodes. Also when the filters are getting run we would be able to pass through a an array of variables which can be used by the filters. I think that I have my 4.8 project. What do people think. Thanks in advance. Gordon.

Hi, On Wed, 2006-04-12 at 08:49 -0400, Moshe Weitzman wrote:

Many folks have also advocated for this so you are in good company. Since Steven will have to bless this patch, I suggest getting buy in from him on a use case. See his comment at http://www.acko.net/blog/drupal-filter-formats#comment-78

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.

Also see an old patch at http://drupal.org/node/11225. There may be others around too.

I have taken a look at this patch and it is similar to what I want, but it need to be a lot more generalised. ATM this patch makes it a lot more node orientated, where I would like to a lot more generic so that it can be used a lot more throughout the system. Gordon.

On 4/12/06 2:21 AM, "Gordon Heydon" <gordon@heydon.com.au> wrote:

...

Hi,

On Tue, 2006-04-11 at 09:53 +0200, Bèr Kessels wrote:

...

Op maandag 10 april 2006 01:40, schreef Gordon Heydon:

...

Also is it possible to have a filter that is allowed only in certain situations as I would like to turn all the ecommerce emails into filtered fields, but this does not really relate to a node at all.

You may want to look at blocks. They are not node (ugh) and still use the filters.

I have taken a look at this, and it was what I expected.

check_markup() is good if you want to call it in total isolation, ie so what is contained within the content don't really need to know where it is being called from.

In the case of a node with php content you can generally work out what the node is and do a node load to get the data. By this is really a little inefficient, because before calling the check_markup() from node_prepare() we already have the node object, so it would be nice if you can have the $node as a local variable so that you can use it.

Also with the filters it would be nice if they can be more content type oriented. I would like to be able to classify filters so that they only get used on certain types of content. So the current filters would be considered a global filters and would appear on everything, but for E-Commerce I could create a transaction filter class and this will only be display on the emails that are sent from ecommerce, and not in other areas like nodes.

Also when the filters are getting run we would be able to pass through a an array of variables which can be used by the filters.

I think that I have my 4.8 project.

What do people think.

Thanks in advance. Gordon.

!DSPAM:1000,443cfa98140941299430736!

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.

Hi, On Wed, 2006-04-12 at 22:07 -0400, Moshe Weitzman wrote:

...

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 - the best way to make progress on this issue to give use cases and ask people to solve them in an elegant way without enhancing filter system. If no elegant solutions arise, your proposal becomes more justified. Use cases are key.

What I want is to be able to in E-Commerce when E-Mails are sent to be able to use php to develop more complex emails. Maybe even mime based emails with the invoice attached. Also ATM the generation of these emails is quite bad and very inflexible when it comes to customising these for sending invoice information to customers and being able to brand your shop. My first though was to use the filter system since it has the php filter and just more, plus for users this is something that they are use to. When I started implementing this I found that the filter system is too general and really can only filter content based entirely on the content that is past. So when you are looking at the body from a node you cannot make decisions on what to do with the content based upon other fields in the node, without having to reload the node (and make sure that you have the right node). Also I though about creating an ecommerce filter which can be added to "filtered html", but most of the time when sending the emails it will not know which transaction it is working on, and if the content that is being filtered is not a transaction then we don't need to run the ecommerce filter. I did think about adding a flag to say run as php, but then I would have to deal with all the security issues that would normally be done by core. and as I looked at this more I found I would be building a new filtering system. Why should I do that we have a perfectly good one now. If you have any suggestions, please tell me. but I think that adding content based contexts for filtering will give the most benefit. Gordon.

Hi, On Wed, 2006-04-12 at 22:26 -0500, Allie Micka wrote:

On Apr 12, 2006, at 10:10 PM, Gordon Heydon wrote:

...

What I want is to be able to in E-Commerce when E-Mails are sent to be able to use php to develop more complex emails. Maybe even mime based emails with the invoice attached.

Also ATM the generation of these emails is quite bad and very inflexible when it comes to customising these for sending invoice information to customers and being able to brand your shop.

Have a look at the mime mail module - it accepts any HTML string and sends a valid multi-part email. You can simply send the html generated by node_view() or use the existing HTML for your invoice.

As it is global to the site, it retains the site's global theme, and respects the users' html/text preference globally. By default, it includes the site's theme's styles. In most cases, this will successfully retain the site's brand. You can override this via a theme function.

This sounds like an interesting idea, but the emails that are sent for a transaction is not a node. But being able to just pass raw html may be beneficial.

...

My first though was to use the filter system since it has the php filter and just more, plus for users this is something that they are use to. When I started implementing this I found that the filter system is too general and really can only filter content based entirely on the content that is past. So when you are looking at the body from a node you cannot make decisions on what to do with the content based upon other fields in the node, without having to reload the node (and make sure that you have the right node).

Also I though about creating an ecommerce filter which can be added to "filtered html", but most of the time when sending the emails it will not know which transaction it is working on, and if the content that is being filtered is not a transaction then we don't need to run the ecommerce filter.

I think I understand what you are trying to do here, but I don't understand why. What is the benefit of knowing which transaction the filter is working on?

Because then you can display data that is within the current transaction. Gordon.

Hi, On Thu, 2006-04-13 at 01:09 -0400, Lists wrote:

"Gordon Heydon" wrote:

...

On Wed, 2006-04-12 at 22:07 -0400, Moshe Weitzman wrote:

...

...

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 - the best way to make progress on this issue to give use cases and ask people to solve them in an elegant way without enhancing filter system. If no elegant solutions arise, your proposal becomes more justified. Use cases are key.

What I want is to be able to in E-Commerce when E-Mails are sent to be able to use php to develop more complex emails. Maybe even mime based emails with the invoice attached.

Also ATM the generation of these emails is quite bad and very inflexible when it comes to customising these for sending invoice information to customers and being able to brand your shop.

My first though was to use the filter system since it has the php filter and just more, plus for users this is something that they are use to. When I started implementing this I found that the filter system is too general and really can only filter content based entirely on the content that is past. So when you are looking at the body from a node you cannot make decisions on what to do with the content based upon other fields in the node, without having to reload the node (and make sure that you have the right node).

Also I though about creating an ecommerce filter which can be added to "filtered html"

It sounds like a distinction between a "format filter" and a "processing filter". A format filter would conceptually be expected to treat each proper chunk agnostically. A processing filter would conceptually be expected to take specific actions on specific chunks, based on the content of other chunks -- and any of those actions might be applying a content filter.

...

From that point of view, then, it would seem very much like an additional layer or feature, rather than an expansion of the format filtering system.

Already, the 'format filters' UI is very non-intuitive. If that were visually redesigned, so that more preferences or configuration options were present on the same screen, then that might simplify things enough to add an additional sequence of 'process filters'.

I think the idea you are struggling to define is a good one. And, although it could probably be dealt with in other combined ways, a 'processing filters' system seems relevant to any number of cases.

Even the simple idea of having a specific icon appear beside the title of a node, depending on the node type, could be accomplished with such 'process filter' system, if that system were fine-tuned to the level of form elements (or --> data table columns).

Maybe another way to conceptualize the idea is to think of being able to attach random callback functions to any particular form input element. Perhaps this would introduce the idea of even different "flavors" of 'process filter' application.

For example, one attached "process filter callback" might be JavaScript-based, acting on user changes to a form element.

Another "process filter callback" attached to the same element might only be applied in a "data insertion" phase (from form to DB), and even another might be applied in a "data retrieval" phase (out of DB to viewport).

I must admit that my knowledge of the inner workings of the Drupal API is not sufficient to advocate for or against any such idea.

The implementation that I was thinking of would have no changes to the ui except maybe when a filter has no actual filters behind it because there are no global filters or filter in that class.

But I do like the idea.

Thanks Gordon.

On Apr 13, 2006, at 9:56 AM, Mark Fredrickson wrote:

A script should have information about both the person doing the calling and the target individual. (eg. "Hello, my name is {John Smith}, may I speak with {Janet Jones}? Hello {Ms. Jones}, I'd like to talk to you about your key issue, {the environment}..." -- where {} denotes a field from either the caller's or the target's CiviCRM record). I've been storing the script in the node, but the caller and target won't be known until later (when a user participates in the phone bank).

Ok, that I understand. This is being done in a number of places with Drupal (e.g. registration mails). And the code for it would be: $script = strtr($string, $variables); Or, if you want it to be translatable: $script = t($string, $variables); Where: $string = "Hello, my name is %caller_name, may I speak with % recipient_name?..." $variables = array('%caller_name' => 'John Smith', '% recipient_name' => 'Janet Jones'); As you can see, the translation code itself is so succinct that it would be silly to write frameworks around it and it need not have anything to do with filters. The real heavy lifting is populating that $string and those $variables. I don't know how you'd generalize this - it's pretty application-specific. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies

Hi, On Thu, 2006-04-13 at 09:56 -0500, Mark Fredrickson wrote:

...

What I want is to be able to in E-Commerce when E-Mails are sent to be able to use php to develop more complex emails. Maybe even mime based emails with the invoice attached.

Another use case: I'm working on module to create phone banks and other advocacy/campaign contact methods in Drupal. The module integrates tightly with CiviCRM. The critical components of a phone call are: 1) the person called, 2) the person doing the phoning, 3) the script, 4) data collection.

A script should have information about both the person doing the calling and the target individual. (eg. "Hello, my name is {John Smith}, may I speak with {Janet Jones}? Hello {Ms. Jones}, I'd like to talk to you about your key issue, {the environment}..." -- where {} denotes a field from either the caller's or the target's CiviCRM record). I've been storing the script in the node, but the caller and target won't be known until later (when a user participates in the phone bank).

I've written my own preg_replace solution, but it would nice to have a filter where I could pass in a parameters array and let the filter do the work. I think my use case fits in the more generalized solution.

If it content that you are filtering is a node then this can be done now by reloading the node, and processing from there. But if it is not a node, and you can't find the current piece of content by another mean then being able to pass an array of vars would make using this in a filter very easy. Gordon.