You could make an argument for keeping the core limited to stuff that is put there by an official install. OTOH, if they’re all in /core/model/modx/service_name, it makes them easy to find.
MODX Staff
Technically, I would consider these things we’ve termed service classes to simply be classes that may be represented in another model or as a model by themselves. In any case, as long as they are in a model package, you can configure the base location of that specific package, so, ultimately it’s up to you. There is no issue with separation if you keep your packages separate from the modx package, so I would recommend using the core/model location and adding a subdirectory for your specific model outside of the modx/ directory, using a convention like core/model/developer-or-company/specific-component-package/ or core/model/custom-model-name/sub-component-package.
You could make an argument for keeping the core limited to stuff that is put there by an official install. OTOH, if they’re all in /core/model/modx/service_name, it makes them easy to find.
IMO, we should ultimately allow components that consist of more than just a snippet or plugin record in the db to allow the user to configure the location of such files interactively during installation and/or manually via appropriate system or context settings. The reason is, with more advanced configurations, especially multi-site, shared-core setups, some components make sense as shared across all site configurations, and some might be better in their own isolated locations (could also be outside the web server directories) for each specific site or a set of them.
Let me ask something more concrete. For the Mollom package, if it were you, where would you put the mollom class file and where would you put the rest of the files (e.g. ixr_lib.inc, readme, etc.)?
MODX Staff
MODX Staff
Well, yes, but isn’t there going to be a modMollum class to integrate it? i.e. the mollum model contains the mollum files as is, then in modx.mollum you could create modMollum (like modSmarty), if that’s necessary. I don’t know anything about mollum, so I don’t know what is appropriate exactly. It always depends on how the code was constructed.
So you’re saying /core/model/mollom/xml-rpc.lib, right, even though it becomes a service class instantiated with $modx->getService()?
The object becomes a member variable of the $modx instance, and is then instantly available to any code where you have access to $modx. It also can be used multiple times in a request, and will just get the existing service instance if it was already instantiated. It also automatically passed a reference to $modx and an array of parameters to the class so that it can also have access back to $modx if need be. This prevents sloppy reliance on global variables.
BTW, what are the advantages of using$modx-> getService() rather than just including the class file and using "new." ?
Yes, there is a modmollom.class.php and I could certainly do it like Smarty, but since there will then be a core/model/modx/mollom, is there a reason not to put all the files there and keep them together?-- it’s a very small package - one lib, the class file, an example.php andd a readme should do it.
Quote from: BobRay at Feb 14, 2009, 03:39 PMWell, yes, but isn’t there going to be a modMollom class to integrate it? i.e. the mollom model contains the mollom files as is, then in modx.mollom you could create modMollom (like modSmarty), if that’s necessary. I don’t know anything about mollom, so I don’t know what is appropriate exactly. It always depends on how the code was constructed.
So you’re saying /core/model/mollom/xml-rpc.lib, right, even though it becomes a service class instantiated with $modx->getService()?
BTW, what are the advantages of using$modx-> getService() rather than just including the class file and using "new." ?
The object becomes a member variable of the $modx instance, and is then instantly available to any code where you have access to $modx. It also can be used multiple times in a request, and will just get the existing service instance if it was already instantiated. It also automatically passed a reference to $modx and an array of parameters to the class so that it can also have access back to $modx if need be. This prevents sloppy reliance on global variables.
Think of it as placeholders for object instances that might be reusable in multiple components on a page.
MODX Staff
Just the reasons we have already discussed; mostly isolating the external third party artifacts from those that integrate it into MODx specifically. I am going to do this with the xml/jsonrpc as well, since you brought it up.
Yes, there is a modmollom.class.php and I could certainly do it like Smarty, but since there will then be a core/model/modx/mollom, is there a reason not to put all the files there and keep them together?-- it’s a very small package - one lib, the class file, an example.php andd a readme should do it.
Never; nothing in PHP ever survives a page load. To persist objects or data across page loads, you can use PHP sessions, files, a custom database table, or modRegistry.
Does the service object survive a page reload?