* On 27 Apr 2009, Noah Kantrowitz wrote: 
> 
> Yeah, thats a horrible idea right there. It will result in a huge amount of
> memory being used for every page render. Generators are a type of iterator
> that work effectively on-demand. What _exactly_ are you trying to do.

Well, I know, it makes my eyes bleed, but I couldn't find any other
approach.  I want the result more than I want performance in this case.

Two things I'm trying to do:

1. Make a plugin that filters only if a certain token appears in the
   original content.  It's a report/query filter.  I don't want to
   perform the filter for all reports, but there's no way to identify
   exceptions by URL or user ID, only by the content of the page.

   Specifically this is akin to GridModify: I want the page view to
   include forms for modifying tickets via AJAX from the report.  Just
   not all reports.  (This is not a security issue, it's a usability
   issue.)

2. Make a different report filter plugin which extracts ticket IDs,
   looks up those tickets, and modifies the report rows based on the
   tickets' individual statuses.  So the transformation of the HTML is
   dependent on information discovered dynamically for each matching
   XPath expression.

   In fact I'm doing the form modifications client-side in JavaScript
   DOM, but the plugin must discover the dynamic data from Trac and
   insert it into the stream as JS data, and for this it needs to
   select() on the stream that it receives, then insert the JS data
   element, then return the new stream.

Fundamentally neither of these things should be done as filters, but I'm
not up to replacing report and query, and my site is both private and
very small.

Even if I end up doing this differently I'd like to understand why this
destroys add_script()'s effects.

-- 
 -D.    [email protected]    NSIT    University of Chicago

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to