Thanks for your feedback. In this post I will try to address your concerns regarding the events/logging api.
Let me start by stressing the fact that the new api is not just "replacing old log calls". We are doing way more than that in the new apis.
# First, let us consider the logs. In Moodle, knowing "something has happened" is not enough. The old logging interface was fine for that. What we wanted was rich and more importantly consistent logs. We need to know exactly which modules are responsible, we need to know the users involved, we need to know a ton of other similar stuff. We want the logs to evolve more than simple tracking and debugging tool. We plan on building numerous analytic reports based on the logs, hence meta data and consistency is an important part of the whole system. We had free flow data in the old system. This led to numerous inconsistency, for example, the "info" field. If you go through entries in plugins db and find the log calls, you will see the random things that has been put in there, starting from orphan ids, hard-coded language strings etc. These requirements called for making the whole api stricter.
# Secondly, logs are not the whole spaceship here. Events are closely bound with logs. While designing the system we did consider the alternative to keep them separate. Keeping them separate would be asking developers to write more code than present with an added cost of performance. It simply seemed pointless to keep them separate when it was quite obvious that anything that is worth logging should be an event as well. So the work involved to "replace a log", also gives you the added benefit of triggering events which will allow other plugins to interact better with your code.
#Third, we are aware that hooks are needed in Moodle. We already have a proposal in place (see MDL-44078
). But we have limited resources, hence unfortunately the hooks project had to be delayed.
Now lets look into more specific concerns that you raised regarding creating an event,
Create a specifically named class
In a specifically named directory two levels deep
These are Moodle standards and not specific to Events api. For example, scheduled tasks needs to be placed in classes/task. Personally I don't see any reason why this can cause confusion, on the contrary, I would say this makes things more clear and granular. with default required classes
Again not sure, why this complicates things. I see this as a common design pattern. The default class handles tons of things for you, and all you need to do is to extend it. Is it really that complex to extend a class? without any proper data handling, but relying on "other" for much data handling, which:
Does not correctly evaluate values, but due to the construct requires already assigning them to variables before passing it
Have you tried creating an event with in correct base properties? For example - conflicting course-id and context
? or leaving out object-id, while specifying an object-table? If you did, you would know there are quite a few validations already in place. What we leave up to developer is to validate the "other" filed by themselves, as this is a free flow field and only the developer knows what exists in this field. Still there was another proposal to make these fields strictly validated (MDL-45108
), but we decided to delay that, as that would add more complexities to the api. Feel free to suggest alternatives on the issue. providing no standard handling of legacy add_to_log replacement, but requires manual adding of these calls
Have you seen this doc https://docs.moodle.org/dev/Migrating_logging_calls_in_plugins
? requiring at least 20 LOC to achieve a simple "view" call
As I mentioned earlier, it is not a simple log entry to say something has been viewed, it has tons of other things associated. being the most counter intuitive thing I have ever encountered in MY ENTIRE LIFE
Well, Spaceships are pretty rare.
Let's move on to more specifics
So ways to improve: Define default events for default events (view, grade, error, update, delete, etc.)
Do not tie these events and event declarations to specific plugins. Grading an assignment is in no way different from grading a quiz for logging purposes.
Do the above to make it usable with all types of resources in a coherent way (no different calls for mod and block)
Reduce the LOC needed for declaration of events by following #1 by using default events
We have already created default abstract classes for events that made sense(For example course_module_viewed). Creating default classes for "all" view events defeats the purpose of the whole system, it has no added value(crud property already explains its a read event). Allowing a generic event to be triggered from a billion places not only results in the loss of granularity but also makes it very difficult for observers to monitor specific things happening in Moodle. If you have suggestions for more specific situations which would be consistent among plugins, please bring those forward, and we will consider creating abstracts for the same. Do not require redeclaration of all functions before you can use them (duplication is the worst sin in MVC patterns)
You don't have to redeclare a single method if you don't want to override anything. For example see mod/choice/classes/event/course_module_instance_list_viewed.php REMOVE the dependency on "other" for almost half of the events, like SERIOUSLY????
What is wrong with using information from other field to make the description of the event more rich? Provide usable examples of events to be created for real plugins, not some loosy-goosy partial examples that actually cover different plugins, but look like they are part of the chainhttps://docs.moodle.org/dev/Migrating_logging_calls_in_plugins
seems pretty clear to me. But feel free to suggest improvements. Create vocabulary for events, so not every plugin has to re-declare vocabulary (which also means that all of the events in Moodle are currently not multilanguage, but english only, just look at all the hardcoded strings in mod_assign)
There is already a vocabulary for verbs used in the events specs. As far as hard coded language strings in the get_description() are considered, these are designed only for admins. There is an issue to return translatable strings to be displayed to users in reports (see MDL-45106
) If you want to make Events 2 actually usable, add hooks support as default
Simplify the event handling and requirements, it's not a spaceship, they are log messages
Provide proper error handling for events, breaking debugging output because a not yet fired event is invalid is retarded
See initial part of this post. Class autoloading would be useful if it actually auto-loads, not requiring increasing versions to trigger upgrade for every single change or addition
To make the autoload work faster we have implemented a cache, when you add a class you need to purge this. Changing version numbers is simple a way to do the same. If you are writing code, you should be doing this with developer mode on which doesn't need purging of the cache. (https://github.com/moodle/moodle/blame/master/lib/classes/component.php#L160
I understand that the whole system is a bit more complex than what it used to be, but everything that is there, is there for a reason. We welcome all constructive feedback on how we can simplify this for plugin developers, but simply saying that everything is useless is not the right approach.
If you find docs that are incomplete or not clear, please feel free to provide suggestions and we will do our best to incorporate the same.
Hope this post clarifies a few things.