$modx->invokeEvent("OnBeforeDocFormSave", array (
"mode" => "upd",
"id" => $id
));$modx->invokeEvent("OnBeforeDocSave", array (
"invokedFrom" => "docForm",
"mode" => "upd",
"id" => $id
));
MODX Staff
I do want a reliable central location that can react to changes in the data, similar to database triggers, but since MySQL’s triggers are rudimentary, they’re not powerful enough to do more complex actions. If the system events are tied so closely to the form in Revolution, what are the alternatives? How would I be able to write a script that reacts to database changes?
IMO they need to remain as they are, because moving forward (i.e. in Revolution), the events are very specific to the forms. I understand what you are wanting, which is a central location with which to control changes to the data, and this is exactly what Revolution’s OO approach attempts to address, but not using events (though they are no doubt still utilized greatly for extensibility).
I have a functioning plugin on my site that retrieves those values rather easily, i.e. simply by using the $_POST variable. It may be nice to have those values built in to the system event, but I don’t think it’s absolutely necessary. In any case, passing that information along shouldn’t have a detrimental effect on existing scripts. It might pass more information than necessary for some scripts, but that’s not a problem.
It would also require that more data be passed to the events; just having the id there if you don’t have the POST/REQUEST values you expected in the context of the forms isn’t really very useful.
I’m not sure why this would create a rift. It still passes the same information to existing scripts, while also proving additional information to scripts that need it.
If I didn’t think it would cause a huge rift in the migration process, as well as for existing sites 0.9.x sites and custom code during upgrades, I would otherwise agree with the proposal.
MODX Staff
It’s called an object model; you extend objects to extend their behavior, and all of the code is centrally available regardless of where or how it is called.
I do want a reliable central location that can react to changes in the data, similar to database triggers, but since MySQL’s triggers are rudimentary, they’re not powerful enough to do more complex actions. If the system events are tied so closely to the form in Revolution, what are the alternatives? How would I be able to write a script that reacts to database changes?
It shouldn’t have to get that data from the POST, which won’t always be available; it should be passed explicitly from any kind of input mechanism.
I have a functioning plugin on my site that retrieves those values rather easily, i.e. simply by using the $_POST variable. It may be nice to have those values built in to the system event, but I don’t think it’s absolutely necessary. In any case, passing that information along shouldn’t have a detrimental effect on existing scripts. It might pass more information than necessary for some scripts, but that’s not a problem.
Because every plugin tied to those events would have to change to accommodate the event parameters changes, all the plugins assigned to those events would have to be modified, and some just wouldn’t make sense anymore unless it was related to the form and had all of the form details available to it.
I’m not sure why this would create a rift. It still passes the same information to existing scripts, while also proving additional information to scripts that need it.
If this really does substitute for system events and can be triggered every time an item is saved, deleted, edited, etc., that would accomplish everything I want it to. But I worry that I won’t be able to catch all of the events, or that I’ll have to route events through the extension of an object, rather than directly to the core object, which means rewriting the way objects are called in the core. I’ve been looking at the code for Revolution, but it’s different enough from the code that I’ve been working with for so long, that I admit having some difficulty navigating through it all and trying to figure out how everything is connected. So my worries may prove unfounded, but at least at this point, I still worry.
It’s called an object model; you extend objects to extend their behavior, and all of the code is centrally available regardless of where or how it is called.
I was suggesting leaving the existing parameters, and adding new ones. Existing plugins would still work, I would think, because the old parameters wouldn’t change.
Because every plugin tied to those events would have to change to accommodate the event parameters changes, all the plugins assigned to those events would have to be modified, and some just wouldn’t make sense anymore unless it was related to the form and had all of the form details available to it.
Yes, there would be some overhead. That’s to be expected with any script though. As long as you want the script(s) to be triggered, that’s a trade-off that’s unavoidable, no matter what you’re trying to accomplish, whether with system events or snippets or anything else. Just like it is now, the modx administrator would be the one making the decision to enable the plugins or not. At least that’s my perspective on the pre-Revolution code.
This is not to mention the added overhead of calling these events anytime an object was saved or modified, which would require the events to be invoked inside the objects. IMO, having custom classes for these things is much more flexible and provides a more constistent way to interact with them.