listManager and postManager (?)

[Lynx]

I've seen some codes that used the listManager and / or postManager (I think I got those right). Is there anywhere that documents what these do and what they're used for - and perhaps how they are useful in a plugin?

Thanks!

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Feb 22, 2016 15:03:09 GMT -8 Lynx said:

I've seen some codes that used the listManager and / or postManager (I think I got those right). Is there anywhere that documents what these do and what they're used for - and perhaps how they are useful in a plugin?

Thanks!

support.proboards.com/post/6439264/thread
There is no docmentation on these items that I've ever found. Reason being that they are proboards behind the scenes functions that frankly are rarely used by developers. Chris is your expert.
From what I see, they hold data on posts that the server uses to do all moderations such as selecting, likes, deletion, etc.

[Chris]

You should be aware that Pat has said in the past that if you choose to use undocumented methods then you also need to be prepared for unannounced changes which could cripple or even obsolete your code. With that said however the list manager used to be saved to a global variable named listman but was not consistently available so it was revamped to save the reference to a newly created namespace of proboards.listManagers and with a structure that now supports multiple references that suggested (at least in my own demented mind) that it was revamped with developer usage in mind even if not officially announced.
You can grab the listManager currently in use via proboards.listManagers[pb.data("lm_id")] so try sending that to your javascript console to inspect the various properties and methods available and get a better idea of what it keeps track of and what it can do. One thing however that truly demonstrates the warning regarding using undocumented methods has to do with the selected_ids property (at least last I looked) since the use of hidden checkboxes were created to keep track of selected posts rather than using the existing system by some newly added code making it once again unreliable.

The one thing I've found use for this in the past was as a way to test if I'm on a page that contained posts (as opposed to threads) without having to hunt down all the different routes that yielded posts, even the obscure ones such as "posts_by_ip",  and also as a way to grab references to items such as pagination without being subject to changes made by templates or other codes. I can't remember if I've ever use postManager except to create a reference for a code that depended on closure variables that were no longer bound, I could be wrong though and have just forgotten since some of the methods seem awfully familair

[Lynx]

Thanks for the reply, Chris!

The reason I was wondering is because of the RP Translator that I'm working on (although "production" on that has halted until V6 now). In the code you gave me, at the bottom, you had used the Search in the navbar for the example there for the button to click to open the dialog. What I was hoping to do was to have a button created on a posting page (next to the Quote, or in that line of buttons, for example), but wanted to make sure the user was on a posting page to make the button. I hope that made sense. If you want, I can paste that part of the code for you to look at - if you want to refresh your memory.

[Chris]

Please remind me, I unfortunately have no recollection of which code you speak.

when you say you want to add a button next to the quote button that sort of of suggests you want to activate on a page that lists posts (either as in a thread or as a result of a search returned in post list form) and not the posting page (for clarity, the "posting page" refers to the full reply wysiwyg page) ??

[Lynx]


/* Set a link on the page that will open the dialog when clicked (using search in navigation for this example) */
$('header a[href^="/search"]').click(function (event) {
/* "YOU SHALL NOT PASS":
suppress the action this click usually performs, in this
case we are rerouting the link that normally takes us to
the proboards search page so it opens our dialog instead
(JUST AN EXAMPLE!!)
*/
event.preventDefault();
event.stopImmediatePropagation();
//open sesame
$dlgElement.dialog('open');
})


And yes, you are correct. My apologies for incorrect terminology. I would like it to show on pages that posts are shown, such as when viewing posts in a thread or post lists returned from a search.


Just in case you want the full code for context:

function setupSearch() {
var template = '<div id="my-search-dialog" style=""><form id="my-form">'
+ '<div class="field1 lookup micro-profile"><label for="input_field1" class="lookup-label">lookup via blah1:</label><input name="field1" id="input_field1" placeholder="search..." style="float-right"></div>'
+ '<div class="field2 lookup micro-profile float-right"><label for="input_field2" class="lookup-label">lookup via blah2:</label><input name="field2" id="input_field2" placeholder="search..." style="float-right"></div>'
+ '<div class="results lookup miniprofile" style="width:458px"><label for="textarea_results" class="cal-preview-panel">results</label><textarea readonly name="results" id="textarea_results" rows="5" style="width:96%"></textarea></div>'
+ '</form></div>',
$dlgElement = $(template), //turn the html into an element
$form = $dlgElement.find('form'), //save reference to the form for quick access
$inputs = $dlgElement.find('#input_field1, #input_field2'); //save reference to the typing fields for quick access

var errptr = 0,
errormessages =[
"Please type something before searching",
"Please remember to type something before searching",
"Please consider typing something before initiating a search",
"Did you remember to type a search term first?",
"Is there a problem here? What happened to the search term?!",
"OMG! You didn't just do this again! I CANNOT search unless you provide a search term!",
"Why are you being an @#$&*)&^ ? Type something FIRST!!!!",
"Look buddy, I'm in no mood for games, type something BEFORE SEARCHING!",
"How many times do I have to say this!!? TYPE A #$%^&*@ SEARCH TERM FIRST!!!",
"Is your keyboard broken perhaps? Press ALT + F4 to test it :)"
]

/* "HE IS THE ONE!" : make input usage mutually exclusive (there can be only one) */
$inputs.on('keyup mouseup', function () {
// only disable if there's an actual value
//(e.g. backspacing to clear what was typed will re-enable the other input)
if (this.value.length) {
$inputs.not(this).attr('disabled', 'disabled').attr("placeholder", "");
} else {
$inputs.not(this).removeAttr('disabled').attr("placeholder", "search...");
}
})

$dlgElement.dialog({
title : 'Search for blah blah blah',
autoOpen : false, //"WAIT FOR IT": do not open right away, wait for the designated link to be clicked
width: '470px',
buttons : [{
text : 'Lookup',
id: 'lookup-button',
click : function (event, ui) {
var val = $inputs.filter(':enabled').val();
if (val.length) {
$( '#textarea_results' ).append( 'seaching..."'+val+'"\n' ); //using append instead of val to simulate a log

/* CODE FOR LOOKING UP AND SHOWING STUFF GOES HERE */

}else if( $inputs.eq(0).val() == "" && $inputs.eq(1).val() == "" ){
if( errptr >= errormessages.length) errptr = 0;
pb.window.error( errormessages[errptr++] );
}

/* enable any disabled inputs and reset to default state after results (or error) has been shown */
$inputs.removeAttr('disabled').val("").attr("placeholder", "search...")
}
}, {
text : 'Close',
id: 'close-button',
click : function (event, ui) {
$(this).dialog('close')
}
}
]
})

/* Set a link on the page that will open the dialog when clicked (using search in navigation for this example) */
$('header a[href^="/search"]').click(function (event) {
/* "YOU SHALL NOT PASS":
suppress the action this click usually performs, in this
case we are rerouting the link that normally takes us to
the proboards search page so it opens our dialog instead
(JUST AN EXAMPLE!!)
*/
event.preventDefault();
event.stopImmediatePropagation();
//open sesame
$dlgElement.dialog('open');
})
}


[Chris]

So basically you're looking to use the list manager to test if you're on a page that lists posts. The code present in this post uses it in just that way with the line:

if(window.listMan && listMan.item_type/*effectiveType*/ == "post" /*"posts"*/){

first it tests for the global variable listman then if it exists tests for item_type equaling "post" (in previous versions it was called effectiveType and was equal to "posts" ergo the commented out parts). If that conditional evaluates to true then you could be sure that you are on a page that lists posts without having to worry about the different incarnations the route might take to get you to such a page. For the record, instead of listman I would use the newer reference saved in proboards.listManagers if I was writing that code today since the listman variable could very well be taken away plus it doesn't even exist on some pages so something along the line of:

if(pb.data('lm_id') && proboards.listManagers[pb.data('lm_id')].item_type == "post"){
//code that depend on being on a page with listed posts goes here
}

[Lynx]

Thank you very much, Chris. That helps immensely!