[development] check_markup() question

[Gordon Heydon]

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.