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.
> * 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).
> 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.
--
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.
