Most functions in the MODx manager menu should have ready classes with their methodes in the MODx object model. Otherwise it is nearly impossible for most programmers to develop applications on the MODx layer. They would have to completly understand the database model and xPDO model, of course.
For example, what I miss today is this:
I have ’authors’ who may fetch ’reviewers’ for their article. What I need as codeable modx functions in PHP snippets is the same what an admin would have to do by hand.
The interesting issue is that all those functions must already be coded; otherwise it wouldn’t be possible that the Revo manager could work. The task is "only" to spend them a useful modx layer.
So, I hope that I can cause some progress by new suggestions about missing methods (or classes, too). But it is of course difficult because the class documentation is very raw (i.e. there are no or too less bridges from the Revo documentation to the Revo API phpDocs). Okay. Now some wishes:
See Revo Manager menu:
Access Controls -> Update User Group -> Resource Group Access -> Add User Group
The modx equivalent could be something like
(modResourceGroup) $resourcegroup->joinGroup($usergroup, $minimum role, $context);
Then your resource itself needs an connection to the user group.
(modResource) $resource->joinGroup($resource_group);
And the other way arround by leaveGroup.
Or should I prefer to make inputs in the bug tracker?
These would be excellent issues for the bugtracker. Thanks.
shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect |
github |
splittingred.com
-
MODX Staff
- 10,725 Posts
The kinds of specific suggestions are exactly what we need in our tracking system. Thanks for taking the time to provide this feedback.
Also, I want to point out that there are two layers to use here, one being the model layer, and one being the processors that tend to decorate the model methods with additional behavior that generally is not necessary to managing the object’s data directly, but provide a standard way of performing an action on the model. Obviously, context-specific security cannot be handled in the model layer; this has to be checked in the processors and for this reason, when looking to implement standard content management actions in your components, you could look at using the appropriate processor via Ajax or API, see $modx->executeProcessor().