[development] special filter behavior for teaser

[Rob Barreca]

>
> No. We have two ways in general: inline, and metadata. What you propose is 
> metadata, what Dave wants/needs is inline. Lets not confuse the two.
>   

Correct, that's why I added this footer to my original message. Just 
wanted to throw the metadata approach out there in case he wasn't aware 
of it. 
> If you need to use img_assist (using inline images), you could do this 
> in hook_nodeapi() as Steven says and shrink down any images, but this 
> method is a bit clunkier.
In terms of the performance issues, the image regeneration could be in a 
form_alter #submit handler before node_submit() fires and then the 
processed teaser would overwrite Drupal's generated teaser allowing us 
to cache the resized image teaser. Or, am I missing something?

 From node_submit():
<?php
  // Auto-generate the teaser, but only if it hasn't been set (e.g. by a
  // module-provided 'teaser' form item).
  if (!isset($node->teaser)) {
    $node->teaser = isset($node->body) ? node_teaser($node->body, 
isset($node->format) ? $node->format : NULL) : '';
  }
?>

Rob Roy Barreca
Founder and COO
Electronic Insight Corporation
http://www.electronicinsight.com
rob at electronicinsight.com



Bèr Kessels wrote:
> Op dinsdag 6 februari 2007 08:19, schreef Rob Barreca:
>   
>> The best way IMO is to use CCK and imagefield/imagecache. Then you have
>> an "image" field and can call a different imagecache preset in your
>> node-content_whatever.tpl.php file when $teaser is true/false. This is
>> what I have used in the past for this functionality and works quite well.
>>     
>
> No. We have two ways in general: inline, and metadata. What you propose is 
> metadata, what Dave wants/needs is inline. Lets not confuse the two.
>
> The camp that want the node/comment/foobar objects to be passed to the filter 
> have so far lost the battle (see Stevens comment) for good reasons (IMO). 
>
> But.
>
> Right now, you see all the more advanced filters being implemented as 
> _nodeapi, and not as filters. A bad, bad result, IMO. Much worse then the 
> argument of 'clean implementation'. 
>
> We see (rather popular) modules such as inline.module being real performance 
> drainers on your site. Also the filter tips can no longer be used properly, 
> and you don't ave the filter available in filter settings. 
>
> I think that Dave is best off using that method too, here. Its unfortunate, 
> its a performance problemn, and the interface becomes clumsy (filter tips 
> cannot be reused etc) but at least it works. ;)
> Look for an example at inline module. http://drupal.org/project/inline
>
> Bèr
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070206/d41e5f86/attachment-0001.htm