If you set the instance parameter in each snippet call and append the appropriate value to the re-post links in the tpls, the snippet code would know what instance it was responding to...Your thoughts are just right, that’s what I did and want to share. If an "instanced" form is posting to the snippet, it posts the instance name as well, so the code will know what to do. The problem is that I did alter the code at so many places by small amounts - like making "[+".$instance."placeholder+]" from "[+placeholder+]" and changing much of the switch case "servicenames" to switch case $instance."servicenames" and so on, that it doesn’t make sense to post it to the forum.
Since this thing has a Wiki, you think we should move the documentation into it, since we’ll have to update/edit Scotty’s eventually?If the whole directory of html and .js files could be moved and also been "version-tracked" or updated in Google then it’s worth to do it, yeah! But I don’t know how it’s doin’...
I connected successfully to w/ the SVN client. Could someone else upload the files for the pending 1.3.2 release...Never using an svn though I’m quite sure it’s needed to first upload an initial version.
Quote from: BobRay at Aug 05, 2008, 03:35 PMIf you set the instance parameter in each snippet call and append the appropriate value to the re-post links in the tpls, the snippet code would know what instance it was responding to...Your thoughts are just right, that’s what I did and want to share. If an "instanced" form is posting to the snippet, it posts the instance name as well, so the code will know what to do. The problem is that I did alter the code at so many places by small amounts - like making "[+".$instance."placeholder+]" from "[+placeholder+]" and changing much of the switch case "servicenames" to switch case $instance."servicenames" and so on, that it doesn’t make sense to post it to the forum.
I’m gonna implement all these changes in a raw 1.31 to post it to /group/webloginpe. I’ve never used an svn yet, but once I saw the versiontrack highlighting of MODx, and hope it’s something easy to use.
Since this thing has a Wiki, you think we should move the documentation into it, since we’ll have to update/edit Scotty’s eventually?If the whole directory of html and .js files could be moved and also been "version-tracked" or updated in Google then it’s worth to do it, yeah! But I don’t know how it’s doin’...
$requestInstance = $_REQUEST['wlpeInstance'];
$requestInstance = empty($requestInstance)? "" : $requestInstance ;
$parameterInstance = isset ($wlpeInstance) ? $wlpeInstance : "";
/* set $instanceMatch to false *only* if both are set and they don't match.
Otherwise, everything works as before.
*/
$instanceMatch = true;
if ( ($requestInstance != "") && ($parameterInstance != "") {
if ($parameterInstance != $requestInstance) {
$instanceMatch = false;
}
}<a href = "[~[*id*]~]?service=viewprofile&username=[+view.username+]&wlpeInstance=one">[+view.username+]
<a href = "[~[*id*]~]?service=viewprofile&username=[+view.username+]&wlpeInstance=two">[+view.username+]
switch ($service) {
case 'viewprofile':
if (!$instanceMatch) { // added
return; // added
} // added
etc.
}
☆ A M B ☆
Ditto uses the dittoID variable; you might want to check it and see how it uses it.
I needed two user lists on the same page, both with working viewProfile links (each with its own tpl).Did you try this?
I tried setting a $wlpeInstance placeholder and using it in the tpls but they’re processed too late and always get the one set in the second snippet call.If you’d let the snippet to write instancename in the form/tpl, it would end up with the second instance’s name in both forms/tpls. That’s why you must hardcode the instname to your forms and tpls. Alternatively give a try to not "instancing" both snippets, only one of them.
if (file_exists(MODX_BASE_PATH.'assets/snippets/webloginpe/lang/'.$lang.'.php'))
{
include MODX_BASE_PATH.'assets/snippets/webloginpe/lang/'.$lang.'.php';
}
☆ A M B ☆