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.