Ok, that makes sense. Sorry for being so slow in this.
The more I think about it, the more I’m not sure this package should really be a service (the same goes for captcha).
Maybe I’m still misunderstanding services, but it seems to me that the main requirement for service-worthiness would be:
1. Likely to be used by more than one component on the same page.
(The mollom class doesn’t really qualify here. People will make multiple function calls on the same page, but the mollom object would persist across them. )
Most of the other advantages you mention, it seems to me, could all be accomplished by just having a component class with some static member variables and pass it a reference to & $modx in the constructor. It’s trickier in PHP4 but, I think, still practical.
With respect to security, it gets more complicated. Putting the example .php file in the core only protects it if the core is outside the web root. Many *components* might have a .php file, either for inclusion or as an example (almost all do in 0.9.6). We could have people put the components dir. outside the web root. I’m not sure how many people would do it. Frankly, I wonder how many people will actually put the *core* dir. outside the web root, even though we’ve made it possible. Maybe renaming the .php files to .php.txt isn’t such a bad idea after all, or putting die(’Remove this before use’); as the first line.
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.
Um ... These two statements are somewhat contradictory.
I knew that, I was just wondering if MODx might be stashing the service object somewhere. I should have made my question clearer.
PS: It’s mollom, not mollum.
It’s a palindrome, but before I knew that, I made the same mistake a bunch of times (in the code, where it counts double against you).
MODX Staff
)
)?
