On 4/11/13, Andrej Golcov <[email protected]> wrote:
> Hi,
>
>> Just in case you are not aware of it: There's an old open ticket #8834
>> "Add a generic
>> IResourceChangeListener".
>> http://trac.edgewall.org/ticket/8834
> Very interesting discussion on similar subject. It's a pity, it was
> not reflected in a code.
>
>> Summary of comments 1-8:
>> * Resources vs. Model instances: Passing model instances as parameters to
>> the listeners was preferred. (As in your patch.) Comment 2 suggests not
>> calling them resources to avoid confusion.
> Correct, not all entities exposed via IResourceChangeListener are
> actually resources e.g. Version, Component and AbstractEnum based
> classes. As an alternative, IResourceChangeListener could be renamed
> to something like IEntityChangeListener or any other more appropriate
> name.
>
The fact that they are not resources is just because they are not
associated to a resource manager . I see two options (maybe more ...)
:
1. as stated above to relax the scope of the interface
and rename it to `IEntityChangeListener`
2. Upgrade those entities and transform them into
resources .
IMO , if an entity is so relevant and there's an interest in
broadcasting events to listener components this way then
a. there should be associated state (not limited to DB
e.g. VCS backend)
b. there should be something (request handler, admin panel,
admin command ... but not limited to this) action upon
that state
c. there should be a way to keep track of operations in (b)
e.g. repository hooks
Consequently IMHO such entity deserves to be treated as a resource .
If those conditions are not met it's just either a transient object ,
a field value , ... IMO Resources should be the minimal unit of event
dispatching at this level of abstraction .
>> * Comment 1 proposes interfaces based on experience from AnnouncerPlugin
>> (which has a similar generalization built on top of the existing listener
>> interfaces).
>> One detail I find interesting there is that the event types are generic
>> as
>> well. You seem to be using similar event type identifiers, but only
>> internally when you call _notify('resource_created', ...) etc. Have you
>> considered also exposing these in the interface and allowing e.g. plugins
>> to
>> define new event types? Bad idea?
>
> IMO, triggering of events could be improved and made in more generic
> way. But we can start with simple current implementation and improve
> it later. From the listener prospective, using of non-generic
> interfaces is more convenient (let's say aspect oriented) and provides
> documentation by code. While more generic events make developer to
> rely on documentation (that is
> not the strongest part of the open-source).
>
Like I said in a message sent to [email protected] (<=
citation missing) if I had to choose among an architecture that would
have to be changed every time a new event type is needed and another
more stable in time I'd rather choose the later . Practicality beats
purity . There are no such things like aspects in Trac .
However that does not mean that the methods in interface signature are
all wrong . Indeed that's the barely minimal set of event types that
every resource should support . Nevertheless by doing *only* that ,
plugins are not able to reuse the event processing loops to dispatch
other kinds of events they might want to deliver to some listener
classes .
>> You seem to prefer handling things like
>> wiki_page_renamed or attachment_reparented using the catch-all
>> resource_changed event.
> A listener may subscribe for the specific entity type e.g. only
> attachement and/or wiki page etc.
> In current proposal, wiki_page_renamed and attachment_reparented are
> mapped to IResourceChangeListener.resource_changed event. . We tried
> to find some kind of common denominator in the suggested proposal -
> not all entities support rename operation. I think, that "was_renamed"
> flag can be part of the event context for those entities which have
> rename operation.
>
The way I see it the fact that a given resource is reparented not
necessarily means that its state changed . What really changed was a
relationship external to object state .
For instance in the case I mentioned in a previous message when parent
is a given product (say it in Bloodhound or in another plugin like
trachacks:SimpleMultiProductPlugin) and resource is moved from P1 to
P2 then reparenting is another thing substantially different as
compared to what happens by just editing some fields and keep it where
it is . In the case of attachments it works exactly the same . Editing
means new description , etc ... e.g. a single DB operation whereas
reparenting involves moving files to a different folder , a new whole
set of authz permission rules , ...
--
Regards,
Olemis.
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
