Starting my revolution

You need to point it at data for specific contexts (like the web context) that contain Resources so it can load that context’s data to work with.

.
Yes Ok, but how?

I think the concept of 3rd party components having their own context/namespace is fine, it promotes separation and allows extensions to be added without polluting the ’mgr’ or ’web’ context which I think is undesirable. Also how do we package this? I can have my own hierarchy under assets(within reason), how do I install my code into the manager directories?

Do we really want all add-ons(that extend the manager) to be physically installed in the manager hierarchy? I think not, this just looks like a bug to me, if the context your in doesn’t have the resource you need you should fall back to the ’parent’ context. What I’m saying is that contexts should be derivable, i.e context ’docmanager’ extends context ’mgr’ rather than being totally different.

Just thoughts

OK, the solution turns out be straightforward in this case, for the document in question just get its context_key, we need to do this as we don’t know which context it is in, we can’t assume ’web’ here, then do this . This seems to work Ok now.

Quote from: shamblett at Feb 04, 2009, 06:09 AM

OK, the solution turns out be straightforward in this case, for the document in question just get its context_key, we need to do this as we don’t know which context it is in, we can’t assume ’web’ here, then do this

$this->modx->switchContext($context_key);

. This seems to work Ok now.

Switching contexts switches everything, including system settings. You don’t want to be in web context when using the DocManager to manage the Resources in web context. So I’m not following here. Permissions for DocManager would be assigned to it’s own context or the mgr context, where it’s permissions and settings live.

Bit more info, this happens in the back end processor for the change template request. The modx instance I’m using is created in the connector, with a context of ’connector’ (from the docs again). We then do the get request/handle request. Looking now I don’t seem to instantiate a modx object with the docmanager context as I thought above. Anyway I think this object is transient, so when I switch contexts it works, then we exit. On the next request the modx object is re-created, so nothing gets permanently changed/damaged here.

Looking at this again I’m confused at what’s going on here, I keep getting mixed up between controllers and connectors. Now that I’ve got the change template function working completely I need to look at this again and straighten in my head what the flows of control are here. I also need to do more testing. I need to make sure that the switch really is transient and has no knock on effects for other doc manager functions.

I’m just telling you that even though switching contexts may be transient to your request, it’s not the intention for management code to run in the context it’s managing. You don’t run in application B’s context from Application A just because the function of application A is to manage resources contained in application B. You’ll need to load up the context perhaps, to get some of it’s data, but not switching should take place unless you are redirecting or forwarding a request to a resource in that context. Your code, it’s permissions, and it’s configuration, are all tied to the context it resides in. It’s the "environment" for your code to run in.

And FYI, we’re going to be removing the connectors context completely. After some further discussions on the subject, Shaun and I decided that connectors should be executed in the context that is calling them. I believe this may help reduce some confusion and unnecessary complication with regards to security and management of contexts. I am working on this in a separate branch and it should be done and merged back in sometime today.

Quote from: shamblett at Feb 04, 2009, 09:42 AM

Looking at this again I’m confused at what’s going on here, I keep getting mixed up between controllers and connectors. Now that I’ve got the change template function working completely I need to look at this again and straighten in my head what the flows of control are here. I also need to do more testing. I need to make sure that the switch really is transient and has no knock on effects for other doc manager functions.

You’re also swimming in uncharted waters, too. We’re figuring this out literally at the same time, and trying to nail down these processes before beta. This is, in a sense, a reason we’re still in alpha. Don’t feel bad if you’re running into these issues - we’re trying to sort them out as well. There definitely isn’t a de facto answer for this yet.

Like Jason said, we’ll be removing the connector context, so that when you’re in your docmanager context, your connector/processors will actually execute on the docmanager context rather than some ethereal ’connector’ context. This should simplify things a bit.

As for the separation of 3rd party (3P) manager pages into separate contexts, and the side-effect that it creates with security policies; well, we’re working on that. We’re trying to find a solution that keeps the 3P files separate from the manager, provides the 3P component with its necessary paths and urls, and still allows the 3P to access basic mgr securities.

If you have suggestions, feel free to shoot them over.

Okay, so as of the latest SVN, we’ve changed modActions to no longer have a `context_key` column, but rather a `namespace` column. This means modActions are now tied to modNamespaces. In your modNamespace for your 3PC (3rd party component), you’ll need to set the path so that MODx can point to the proper controller in your 3PC (3rd party component).

For example, a component called ’Test123’ that had a modAction with the field `controller` set to ’index’, would need to have a modNamespace ’test123’ tied to that action. In that namespace, the path setting would be wherever that 3PC is being installed to. Let’s say we’re installing it to: ’assets/components/test123’. So, the modNamespace path would need to be:



This can be set via a new 4th parameter in modPackageBuilder, "path", set like so:



This means 3PCs no longer need their own context. The manager pages, when loaded, will already be in the ’mgr’ context. For now, at least until Jason finishes with removing the MODx connector context, 3PCs will initialize their connectors into the ’connector’ context.

Once we’ve committed the fix to make connectors initialize in their requestor’s context, then connectors for 3PC custom manager pages will initialize in the ’mgr’ context (since they’re being accessed from the manager pages that are initialized in the ’mgr’ context. We’ll try and get some sample code to init the connectors this way as soon as we finish implementing it.

Thanks, no worries with any of this, I realize we are in a fluid situation here, that’s why I think its best to actually try and do something concrete like a real evo to revo conversion, its probably the only way to find and fully understand these issues. I’ll press on as you’ve suggested in the previous posts and make any necessary adjustments and see where we end up.

PS got caught by the renaming of the javascript components, combo-template is now modx-combo-template, if only firebug could be a little more helpful here than giving a somewhat cryptic
constructor error message!

Quote from: shamblett at Feb 04, 2009, 01:49 PM

PS got caught by the renaming of the javascript components, combo-template is now modx-combo-template, if only firebug could be a little more helpful here than giving a somewhat cryptic
constructor error message!

Sorry bout that - all MODx components should be prefixed with ’modx-’ now. If they’re not, they will be before beta.

OK guys, updated to latest this morning, filled in the namespace path for the docmanager namespace and the php side seemed to work OK, i.e modmanagerresponse class found my template path and my controller. Noticed this on line 42 , there is no ’context’ in $act now, minor point.

The main thing that initially bit me was the javascript loading in my template, the existing code didn’t work as we have no context, I can’t use namespace_path here as it wants a URL. I’ve coded this like this at the mo , this is OK now. I’ve got the screen back(piccy below just for a bit of perspective). I’ll carry on testing/merging etc.