Intentional Blocking of Bookmark Navigation
Jamroom Developers
@nate - Thanks for the reply. Bookmarks links are very useful so it was odd to see them disabled. Had to ask.
Forum Activity for @tig
Intentional Blocking of Bookmark Navigation
Jamroom Developers
Would someone please explain the purpose behind blocking bookmarks in jrFollowMe_init()?
$(document).on("click", 'a', function(e)
{
var aurl = $(this).attr("href") || "";
aurl = aurl.replace(" ", "-");
if (aurl.indexOf("javascript") >= 0 || aurl == "" || aurl.indexOf("#") == 0) {
e.preventDefault();
return false;
}
});
I must allow users to navigate using bookmarks. I can easily address this of course, but would like to know the reason for this code to mitigate side-effects.
updated by @tig: 11/19/17 07:54:08PM
Adding custom attributes to comments
Jamroom Developers
@michael - The intended behavior is to leave gaps in numbering to show where a comment is deleted. In result, the child count need only be incremented - the gaps are what we want. But thanks for your thoughts.
My concern is really getting the number of level-0 comments so that I know what high level number the next level-0 comment should be. So assuming we have 1, 1.1, 1.2, 1.2.1, 1.2.2, ... I need to have an efficient method to know that the next level-0 comment will be 2 (with future children of 2.1, 2.2, ...). I can always issue a query of course, but that is what I am trying to avoid. The ideal solution is to store the current number of level-0 children somewhere in jrComments.
Anyway, it was not my intent to consume your time on this so thank you again for your thoughts.
Adding custom attributes to comments
Jamroom Developers
@michael - one of my (safety) concerns is making changes to arbitrary datastores in other modules. It would be quite convenient (for me) to store the child count for level 0 comments (i.e. the number of level-0 comments) in the item referenced by the comment_item_id in the root module (comment_module). No concern if the comment_module is jrBlog, but it could (theoretically) be anything. Seems there would be the potential for name collisions, denied access, etc. If I stay within jrComment the conditions are in my own local control.
Given these unknowns (and realizing that my unfamiliarity with jamroom will lead to wrong-headed overly-conservative ideas on my part) I have focused on a solution that keeps all data changes within the jrComments module.
But I would welcome your opinion on this. I need to store a node count (and a hierarchic node id such as x.y.z) in each comment. The node count holds the current number of child nodes. All is cool except I have no place to store the node count for level 0 items in the jrComments module. Would it be a safe practice IYO to inject data into the comment_item_id item without concern for what the comment_module it might be in? My approach is to, in effect, carve out an area to persist metadata within jrComments (with node count -number of level0 items- being the only metadata at the moment).
Adding custom attributes to comments
Jamroom Developers
Thanks. I am using jrComments threading ... just going beyond what is implemented.
I appreciate the guidance on persistence. Always seek to follow the natural grain of the design so your feedback is greatly appreciated.
Adding custom attributes to comments
Jamroom Developers
Searched the forum but saw nothing addressing data extensibility.
Could someone point me to the 'proper' jamroom approach one should use to add persistent attributes to an item? In my case, I need to add metadata to each Comment. (An example of metadata would be a 'child count'.)
Essentially I would capture the information when a comment is created, persist it (key:value) and then render it as HTML attributes on each comment.
( Background: this is to implement an efficient threaded tree of comments to support new user functionality. )
updated by @tig: 11/16/17 05:16:50AM
Use of blockquote tag in tinyMCE under Follow Me skin
Design and Skin Customization
@michael: "What HTML code are you using when you see the difference?"
I saw the difference when using blockquote regardless of other tags. Whenever I used blockquote it would disappear if I saved via update.
I had earlier on added blockquote to the current quota (moderator). After adding blockquote to the other quotas and checking 'Apply to all Quotas' the update operation then retained the blockquote tag. Since create allowed blockquote and update did not there of course remains an undesirable difference between the two editor usages.
Use of blockquote tag in tinyMCE under Follow Me skin
Design and Skin Customization
It did help. I clicked to apply the change to all and include blockquote. ( I was trying to address this by following the code. )
Although it no longer affects me, create functionality does not seem to strip out tags the same way as update. That is what led me down to the code rather than settings.
Thanks much, Douglas, for the help. Moving on to other experimentation with jamroom!
Use of blockquote tag in tinyMCE under Follow Me skin
Design and Skin Customization
Same behavior (above) with Elastic. The blockquote tag is stripped away when an update is saved for a comment. In result, one can create a comment with blockquotes in it and it will be properly saved but one cannot change the comment and hope to retain blockquote tags. Different persistence behavior between create and modify. Seemingly at least.
( I understand that template code strips HTML for presentation purposes. )
