[development] check_markup() question

[Lists]

"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.

But I do like the idea.

--
Gary