On 4/9/13, Andrej Golcov <[email protected]> wrote:
>> Would it not make more sense if this code were simply committed into an
>> appropriate place in trunk? Or even better, quoted inline in this
>> message, so that it gets archived along with the rest of the mailing
>> list? AFAIU pastbin links are not eternal, which could make
>> reconstructing this discussion from archives a bit of a chore.
Pastebin.com links may be eternal , that depends on how they are
created . For instance , all those I've created in the past for test
reports are public and «everlasting» . The ideal solution would be to
have a pastebin installed in apache.org domain . Ryan and me have been
tweaking trachacks:PastebinPlugin user interface for that very same
purpose in the past . I'm hoping this will be available for us ...
eventually .
> I haven't sent the code in mail since python markup can be messed by
> email
+
besides , at least outside the ASF , it's not a good practice to
submit such texts to public MLs
... to the point ...
[...]
> 'context' is an action context, may contain author, comment etc.
> Context
> content depends on a resource type.
... a comment that's also valid for IResourceChangeListener . In Trac
, `context` is a variable name associated to instances of
`trac.mimeview.api.RenderingContext` (similar to `env` for
`trac.env.Environment`) . Therefore it's a bit confusing in this
context (at least for me that I'm familiar with that term and how it's
used in Trac code base ;) since it clashes with that inherited
*convention*. Is there a chance to name these objects somehow
different ?
1. evt (dojo)
2. eventObject (jquery)
3. EventArgs (C#)
4. ...
If you ask me I prefer (3) or (2) .
>
> def get_subscribed_resources():
> """
> Implementation should return iterator of resource types for which
> a listener has to be notified.
>
> None or empty list means all types of resources.
> """
>
> def match_resource(resource):
> """Return whether the listener wants to process the given
> resource."""
>
+ , these should work exactly the same as listeners will do , though
we still have to find the BH-spot of this subject (see #485)
> def resource_creating(db, resource, context):
[...]
>
> def resource_changing(db, resource, old_values, context):
[...]
>
> def resource_deleting(db, resource, context):
[...]
>
Just a question . Are these methods supposed to replace manipulators ?
- If so , how will they veto subsequent processing ?
- Else , isn't it a fact that methods listed above and
manipulators have a lot of overlapping (duplicated
functionality) ?
* Or maybe the idea is to replace manipulators with
this interface and provide backwards compatibility , just
like has already been done with IResourceChangeListener ?
Beyond that
- add reparent events
- if `old_values` is considered to be yet another instance of
event arguments then all methods will have the same
interface
* which makes me wander whether they should be
merged into a single method plus event name
included as argument or another field in event args
object (i.e. `context` in signatures above)
* and , by doing so , subsystems would even be
able to define their own event types without
requiring major architectural refactoring .
--
Regards,
Olemis.
