On 12 apr, 18:47, Andrej Golcov <[email protected]> wrote: > > 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 . > > Adding new methods does not mean architecture changing. IMO, practical > approach is leveraging infrastructure for repeatable work (events > dispatching in out case) and allowing plugins to concentrate on > business logic.
I like the Trac approach. Each component / sub-system declaring its own resources and providing its own manipulator and lister signatures. I can obviously appreciate where you are coming from trying to add some form of event notifications for various ticket system data as pseudo-resources. Many of which I'm sure share a lot of similarities being based on the same simple enumeration type. Of course, also bear in mind that the Ticket system is just one part of Trac and plugin ecosystem. I see that the natural instinct is to try to rationalise it by lumping everything together to share code. But by sharing the code you have to abstract the data, and in my opinion this is not desirable. It is a design philosophy we have discussed many times in the Trac project. The complex objects passed around with generic no-meaning names line 'context' immediately makes the API non-obvious. You have to look in the implementation and introspect the code to determine exactly what data is part of 'context' and what form it takes. And unlike a method signature it is no binding 'contract' - it is just data that is subject to change at will, either in new versions of Trac or plugins, or just by circumstances from local setup and stored data. Wiki and Ticket were the initial Trac event models. Recently there has been various repository-related events added, and likely more will be added either in Trac or plugins if features such as fork-handling, pull requests, changeset and source line comments and so on gets added. For myself I do resources and listener handling in various unrelated plugins with completely different internals and data structures, like for instance: Bitten (builds and build configurations), FullBlog (posts and comments), Talk (rooms, lines). Having all data hidden in a 'context' argument makes all data non- obvious to say the least. Without an api.py with interface definitions and clear documentation of expected arguments and usage, where are we going to find this documentation? The API should be explicit and binding. Changes should be obvious and documented to the API user. Update the signature, add a new method to denote a new version, or just elaborate in the documentation. Fully generic and hidden implementation has often been described as a 'feature' and a 'benefit' as it allows to modify API without breaking existing code. In theory, not practice. The painful reality is that it just gets much harder to maintain an implementation. The commonly used 'fix' to improve documentation for generic calling is of course to have 'context' refer to some sort of data structure description and version. Like perhaps providing a versioned schema to describe the data passed? This 'XML way' is really not how I would like us to do thing in Trac... Regardless of perceived ease of code sharing, you should not be listening to events that you aren't prepared to handle. You need domain knowledge to know what you get and what to do with the data. And to do more useful work you may even need to be able to use the data to initiate actual model objects or call domain-specific API methods. It all requires know-how that cannot and should not be abstracted and generalized. There can be no meaningful sharing across unrelated domains - at least nothing that can compensate for managing and developing against this new complexity. I see no great benefit of rewriting all implementations to do 'if .. elif .. else' to first check for resource realms, and then calling out to internal helpers to _do_wiki_update_event() for decoding of hidden data and handling of the event. The generic API may look simpler and cleaner, but there is nothing simpler about the actual work and know-how involved in using it. Some things stay the same, some things will just require doing things in a different way. To return to the original post in this thread, how would a search engine listening to events be expected to make sense of the blog, build and chat data it receives in order to update its index? Listeners and Manipulators are not generic problems, and hiding that fact just makes it worse. :::simon https://www.coderesort.com http://trac-hacks.org/wiki/osimons -- 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.
