Quote from: PMS at Jan 05, 2008, 05:40 PM
I’m surprised that no-one has requested an event like that before. I can imagine that it would be useful for automated email notifications and the like, not just XMLRPC pings.
This is why the new core was rewritten in a proper object-oriented form, so you don’t have to use events to do such things. The new API can apply consistent logic when you use the set() method to set the value of a field, e.g. $resource->set(’published’, true) could be extended to apply your logic or we can have it invoke the event there and just make sure everyone calls this function when modifying the data. So even if you do choose the event/plugin route, you still have all logic connected to the event in one function in a single class file, so you are sure the event is always triggered, regardless of who or how the data is manipulated. This centralization of the logic is one of the key attributes of a
Model in the world of MVC design patterns, which 0.9.7 will introduce MODx users to.
Quote from: PMS at Jan 05, 2008, 05:40 PM
I don’t want to modify the core code myself, especially if it’s more than one or two lines that are easy to keep track of. How would I go about officially requesting that this event be added to the next release of MODx? If it’s easy and it was agreed to add this event, could the mods be made to the latest development version on SVN so that I could download the relevant files and start using the functionality immediately? I have never had to deal with a modification of the core code before, so I don’t know the best way of proceeding.
Hmmm, I believe triggering this event with the current auto-publishing mechanism could have negative implications to the performance of MODx sites if not implemented carefully, and this would require a thorough test and review by proof of concept. I would go ahead and just make your modifications and if they prove useful and successful for you, submit them back to the project as a patch attached to a feature request (if you know how to make a patch, otherwise, you could attach the changed files, though that is less preferable). If you don’t feel confident, get someone with skills you trust to help you make, test, and submit the changes back.
In this case, with the rewritten core coming in 0.9.7, I think you can safely make and track these couple of changes you need until 0.9.7 is released (i.e. so you can maintain it while the 0.9.6.x series remains the stable branch). Then, you’ll likely discover much better ways to do this, although I can tell you that auto-publishing is one of the features that is still on the list of refactorings to be completed for 0.9.7 release, as it currently breaks the ability of the new engine to produce pages from cached data result sets without ever having to make a connection to the database. This is due to it delegating the decision to the UPDATE statement (i.e. result cannot be determined without executing the query).