On Fri, Apr 10, 2009 at 10:29:33AM -0500, David Champion wrote: > > * On 10 Apr 2009, Jeff Hammel wrote: > > > > > > How would something like this work with queries/reports? That's > > > the main issue I haven't been able to resolve in trying to develop > > > this sort of functionality. The simple answer would be to store the > > > computed value of the field in Trac's DB, but how would it know when > > > to update the value? > > > > There are two answers that I have been thinking about, neither one of > > which I'm fully satisfied with: > > I've taken a look at this kind of thing too, and my gut tells me that > in these two proposals (as responses to this other poster's question) > you may be attacking two separate but related problems at once. > > 1. There is a need for a provider interface for custom fields and their > possible values -- an extension point to supplant [ticket-custom] in the > config file.
I agree: http://trac.openplans.org/trac/ticket/29 > 2. There is need for an extension which implements this extension point > and may do roughly what you're talking about. I agree here too: http://trac.openplans.org/trac/ticket/28 > I really need #1, but I don't need #2 at all. For my project I would > deliver custom field definitions from an external source, and it > wouldn't matter to me what values currently exist in the db, nor would > I want to alter my db to store any of this information separate from > the custom field values themselves. In my opinion, these are separate > projects. Yes. 2. will build on 1. > To me the best approach to #1 is a patch to trac.core. Sure, but I can write a plugin now instead of waiting for the patch to be in some Trac release. The patch should be written, but personally, I use plugins vs. patches whenever possible > I don't see the > value of implementing as an ITemplateStreamFilter except that you can > currently do it as a plugin... but filtering the stream seems like a > last resort when the basic functionality is already present. Yeah, not needed for 1., probably needed for 2. (or maybe IRequestFilter). > However > there's no existing extension point that you can tap into to offer > the custom field metadata. The only custom field metadata source is > currently hard-coded as [ticket-custom]. Yeah, I agree this is undesirable. > If #1 is implemented as a new extension point in the spot where > [ticket-custom] is now, then #2 is easily a separate plugin implementing > that interface. Likewise, [ticket-custom] can be reimplemented as a > plugin using that interface. Yeah, though I see no reason to redo [ticket-custom]. Its perfectly reasonable for people to put fields there, at least in the forseeable future (I can only think to maybe Trac 0.12 in my mind....and barely at that) > There are good examples of caching the field information already in > trac.core -- [ticket-custom] itself illustrates this. None of these > modifies the db itself, nor would it seem to benefit from doing so. Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
