bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Datamodel and data consistency
Date Thu, 08 Nov 2012 03:48:45 GMT
On 11/7/12, Ryan Ollos <> wrote:
> On Fri, Oct 26, 2012 at 12:36 PM, Olemis Lang <> wrote:
>> [...]
>> What you are doing over there seems to be exactly like batch
>> modifications . isn't it better to reuse batch modification code in
>> query module and make the whole thing to look exactly like if logged
>> in user had selected target tickets , set product=new_product and
>> comment field set to something like «Renaming product XXX to YYY »?
> I had studied the BatchModify class when starting that implementation and
> it looked like the BatchModify class would need some changes in order to
> directly utilize the it. The patch I've implemented does "make the whole
> thing to look exactly like if logged in user had selected target tickets",
> however I could see the advantage of code reuse from batch modify.
> Initially I dismissed this because I didn't want to dip into modifying the
> BatchModify class, but I will revisit this issue and post some comments to
> t.e.o ticket #4582 to see what the Trac developers have to say.

Every few weeks I feel the same about something I have to do with Trac
and most of the time I can find the way to work around that . The
swiss army knife tool I've used most of the time to succeed is
bhdashboard.util.dummy_request . By using it we (mainly Gary and me
... but feel free to add name to the list ;) have been able to reuse
the methods offered by ReportsModule , QueryModule , TimelineModule
and so on in spite of building widgets rendering such content . One of
the situations I can mention we could not handle was the handling of
create ticket shortcut in theme plugin . Hence we incorporated methods
from XmlRpcPlugin . Needless to say that some modifications were
necessary . The most recent example is #195 . In there I combined
aforementioned technique with request filters so as to reuse
AttachmentModule._do_save method to handle file uploads .

Fact is that not doing things this way leads to a situation where
we'll have to maintain some code that does exactly the same Trac does
every day . As a consequence we might end up with situations like
TicketRPC.putAttachment which seems not to take into account
manipulators ... etc, etc, etc ...

That's the reason why , at least until Trac refactors their code to
make it more agnostic to web UI details , I strongly recommend to
reuse their methods rather than rewrite the same thing over and over .

... but you know ... practicality beats purity ... ;)



Blog ES:
Blog EN:

Featured article:

View raw message