On 12/19/12, Andrej Golcov <and...@digiverse.si> wrote:
> Thanks everybody for the useful response.
>
Hi Andrej !
>
> IRequestHandler are appropriate. I wanted to use a request object to
> call add_warning in case of possible indexing errors, of cause, if the call
>
> is in web context.
>
you have a few choices :
1. like I mentioned the natural ITicketManipulator , but that does not seem
to work for you
2. force ITicketManipulator at some point ... if there's
a web request in context
3. bhdashboard.util.dummy_request
4. make the component implement both request aware interfaces
(e.g. IRequestFilter) and ITicketChangeListener , then store
request object in thread local storage (e.g. threading.local) .
I don't know if there's in Trac something like a decorator or
alike for these use cases .
5. however , it seems to me that you are still looking for hooks
operating at model level rather than ticket form validation
to ensure ubiquitous updates for index consistency . This
makes me wonder whether you are better served with
self.env.log.warning . This is related to my note below
about the reason for ITicketChangeListener being
context agnostic . I mean why would you call req.add_warning
while executing e.g. an admin command , an RPC request , ... ?
> Based on your feedback, I will rethink the design to use something similar
> to AnnouncerPlugin for errors notification.
>
> BTW, ITicketChangeListener does not provide all events required to support
> external index consistency. But I would open another thread on this
> subject.
>
it seems so , yes .
:(
>> As the description tells, it's an
>> "Extension point interface for components that require notification
>> when tickets are created, modified, or deleted."
>>
>> Components, no word about sessions, and if you compare it to other
>> interface definitions you'll see, that the missing request is on
>> purpose. This interface was not meant to work in an interaction context,
>> but to enforce side-effects of ticket changes on other Components.
>> That's it.
>
> I would not agree that component that subscribed on ticket changed event
> doesn't need to know in what context the call is happen (context can be a
> web request, trac-admin call or whatever). I believe there are a lot of
> cases for this, like WorkflowNotificationPlugin mentioned by Ethan. I agree
>
That's exactly why ITicketChangeListener does not make references to
web requests . It's operating at model level , therefore agnostic to
context .
> that context should not be passed as parameter but, IMHO, some ortogonal
> context facility will be useful, may be something like
> "env.current_context()" function.
>
hmmm ... Trac is a multi-thread / process web app . Something like
current context does not belong in environment instance but separate
clasess e.g. Request, RenderingContext ...
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
