pb.dialog help

[Chris]

Nov 15, 2015 0:44:37 GMT -8 Lynx said:

Actually, I'm liking the cog dropdown addition to be honest. This means that the only other thing I need to figure out is how to set up so the UI asks for Member Groups so the JS allows only those Groups listed to use it. I'm thinking there will have to be an {if} statement, but the Member Groups would most likely be in an array - which would need a for loop to get them? And if the user is not in a Member Group, then the choice doesn't appear in the (cog) dropdown, otherwise it does. OMG - what have I gotten myself into?

The reason for allowing specific Member Groups (all if none listed in the UI) is for the RP forum I'm making - where only certain Member Groups will be able to use it (RP Members, but spread out in different Clans (Groups)). I'll try my hand at outlining this little conundrum tomorrow - brain doesn't work well at 3:30am. I've still got to work out the rest of the code that Peter gave me for the sliding shoutbox too. I've got to stop trying to do too many projects at once. Oy.

One of the types available when you add a search control to your plugin's interface is "group" and if you set it to accept multiple groups then that will be saved as an array in your plugin settings. All you would then need to do is check if that array has entries and that one of the current user's numeric group identifier matches one of the allowed groups present in the array. Keep in mind that a user can also be in multiple groups so their group affiliation will be presented as an array as well ( pb.data("user").group_ids) or as a plain js object ( pb.data("user").groups).
Once you've determined that the current user can have access to the feature then the best course of action would be to add your menu to the existing list of menus making sure to attach a click handler that suppresses bubbling and issues a manual 'close' command to the menu widget since the default handler will have no idea what to do with that unknown menu (as a button equal to quote, edit, etc instead of a menu that would of course not be necessary)

[Peter]

Nov 13, 2015 13:10:04 GMT -8 Chris said:

Nov 12, 2015 23:35:29 GMT -8 Lynx said:

You are awesome, Chris ! Will you be my mentor?

Thanks but I'm no mentor, I am not even a role model, you should be looking to Peter or Virgil for the technically correct way of doing things

Lynx, don't listen to him, he would be an awesome mentor

I wish when I was starting out I had someone like you to ask questions.  While a lot of it might have gone whooshing past me, your answers are so in depth, they are awesome.

 

[Peter]

Nov 13, 2015 13:10:04 GMT -8 Chris said:

A more reliable way to know when the WYSIWYG is ready is to listen for the custom event that fires after a widget has created an instance: $(document).on('wysiwygcreate', function(event){/* WYSIWYG is now ready */}).

Wow, am kicking my self for not knowing about the widget create event.

When I created the "bbc_button" method for Yootil, I read over widget docs to see what hooks were available, I never once read about the create event. Unfortunately I took the easy way (ready event).

/**
* Adds a new BBC button to the end on the reply page.
*
* @param {Object} img The image element to append.
* @param {Function} [func] Adds an onlick event.
* @chainable
*/

bbc_button: function(img, func){
$(".controls").find(".bbcode-editor, .visual-editor").ready(function(){
var li = $("<li>").addClass("button").append($(img));

if(func){
li.click(func);
}

$(".controls").find(".bbcode-editor, .visual-editor").find(".group:last ul:last").append(li);
});

return this;
}

github.com/PopThosePringles/ProBoards-Yootil/blob/master/src/create.js#L177

Ah well, something to change in the future maybe.

Nice one

[Chris]

I've received what I perceive as hostility in the past for being the TLDR; poster child so I try not to be so verbose

Correct me if I am wrong here Peter but my understanding of the jquery ready() was that is was applicable only to document so even if you called it on a set of jquery wrapped DOM nodes they still wouldn't fire until the DOMContentLoaded (or equiv) fires which may or may not coincide with WYSIWYG being fully ready for use. I get the impression there might be a false connection being made between the use of jQuery's .ready() and the native DOM ready event which applies to certain asynchronously loaded elements or is that particular syntax being used only to confirm the existence of certain elements before running a function when tree is ready. JQuery still binds this to document not the wrapped nodes when used in that syntax.

The `wysiwygcreate` event however does not have "memory" meaning any subscriptions to that event after it has occurred would go unfulfilled instead of immediately firing like the ready() does making it critical it gets attached early in the process. There have been a few improvements since I last did any prolonged pilgrimages into the bowels of the wysiwyg editor namely preloading button images and getting rid of unnecessary ajax calls. This definitely makes the incidents of wysiwyg not being ready by the time DOMContentLoaded fires lower but I still wouldn't rule it out (especially since it employs a subframe with its own document tree). It is probably perfectly acceptable for layout purposes (such as adding buttons) but if you need access to the instance object or the iframe or the underlying widget data then wysiwygcreate is the superior alternative.

That `<widget-namespace>create` event is from UI Factory not the widgets themselves and I don't recall seeing it documented anywhere either but probably came across it either through some fortuitous debugger session or some off-the-beaten-path blog but I'm glad to see you haven't totally written off the "future" despite the barrage of pb.iWant(this) and pb.iWant(that) and still stop in for the occasional debugging session fixes (pun intended) 

I am loving that ubbc_tab method btw!

[Peter]

Nov 18, 2015 22:54:15 GMT -8 Chris said:

I've received what I perceive as hostility in the past for being the TLDR; poster child so I try not to be so verbose

Pfft, don't ever stop what you are doing.

Nov 18, 2015 22:54:15 GMT -8 Chris said:

Correct me if I am wrong here Peter but my understanding of the jquery ready() was that is was applicable only to document so even if you called it on a set of jquery wrapped DOM nodes they still wouldn't fire until the DOMContentLoaded (or equiv) fires which may or may not coincide with WYSIWYG being fully ready for use. I get the impression there might be a false connection being made between the use of jQuery's .ready() and the native DOM ready event which applies to certain asynchronously loaded elements or is that particular syntax being used only to confirm the existence of certain elements before running a function when tree is ready. JQuery still binds this to document not the wrapped nodes when used in that syntax.

The `wysiwygcreate` event however does not have "memory" meaning any subscriptions to that event after it has occurred would go unfulfilled instead of immediately firing like the ready() does making it critical it gets attached early in the process. There have been a few improvements since I last did any prolonged pilgrimages into the bowels of the wysiwyg editor namely preloading button images and getting rid of unnecessary ajax calls. This definitely makes the incidents of wysiwyg not being ready by the time DOMContentLoaded fires lower but I still wouldn't rule it out (especially since it employs a subframe with its own document tree). It is probably perfectly acceptable for layout purposes (such as adding buttons) but if you need access to the instance object or the iframe or the underlying widget data then wysiwygcreate is the superior alternative.

That `<widget-namespace>create` event is from UI Factory not the widgets themselves and I don't recall seeing it documented anywhere either but probably came across it either through some fortuitous debugger session or some off-the-beaten-path blog but I'm glad to see you haven't totally written off the "future" despite the barrage of pb.iWant(this) and pb.iWant(that) and still stop in for the occasional debugging session fixes (pun intended) 

I am loving that ubbc_tab method btw!

You are 100% correct, and I was going to explain in my post at the time in case people were confused, but I knew you would know anyway . The DOMContentLoaded event is bound to the "document" like you said. You can basically jQuery wrap most things from what I have tried, and it will still bind to the document (i.e $({}).ready). I think in this case with that method, I was doing some lookups using the selector, and finally decided to take the lazy way out and throw the "ready" on the end, so unfortunately nothing amazing going on there, it's basically $(document).ready .

I did try a combination of things when I was writing it, I even tried mutation observers which seemed to work fine, but for some reason decided against it (not sure why, as I was going to have fallbacks), unfortunately I can't find it in GitHub, but it was something like this...

$(document).ready(function(){
var target = $(".editor").get(0); // Always there ready to receive the WYSIWYG, so we observe this.
var config = {

attributes: false,
childList: true, // Only interested in added nodes.
characterData: false

};

var ob = new MutationObserver(function(mutations){
mutations.forEach(function(mutation) {
console.log(mutation.addedNodes);
console.log($(mutation.addedNodes).find(".controls").length) // Do we have the control bar to add new buttons.
});
});

ob.observe(target, config);

});

developer.mozilla.org/en-US/docs/Web/API/MutationObserver

Fun stuff

Nov 18, 2015 22:54:15 GMT -8 Chris said:

I'm glad to see you haven't totally written off the "future" despite the barrage of pb.iWant(this) and pb.iWant(that) and still stop in for the occasional debugging session fixes (pun intended)

lol, it's actually very hard getting away from it. I've been doing it for so long now, even though there isn't much motivation, I still have the urge to continue on. I do have a lot of time on my hands right now, as work is very slow coming, but decided that I need to learn new skills that is completely different to what I do now. I've given myself a goal, if it fails, then it's out searching for a new job sometime in the new year.

But yeah, part of me still wants to release plugins (paid plugins would be nice, but not sure when that will be an option for us), the other part of me wonders if it's really worth the time (i.e Monetary System has kinda been a thorn in my side for a few years, way too much time spent on that plugin). I don't know, I may create a plugin and release it at Christmas as a present for people, we shall see . Either way, am not done for good, just for now, sometime in the new year I'm sure I'll be back to releasing new plugins again.

 

[Lynx]

To those who may be waiting for this:

I apologize, but this project has been temporarily suspended due to my poor coding abilities. Therefore, I'm taking a short break from trying to get this to work. In the interim, I'll be looking through W3Schools instructions for learning JavaScript and jQuery. Perhaps all is not lost yet.

My apologies for the inconvenience.

[Peter]

Nov 22, 2015 15:40:37 GMT -8 Lynx said:

To those who may be waiting for this:

I apologize, but this project has been temporarily suspended due to my poor coding abilities. Therefore, I'm taking a short break from trying to get this to work. In the interim, I'll be looking through W3Schools instructions for learning JavaScript and jQuery. Perhaps all is not lost yet.

My apologies for the inconvenience.

NOTE: Codes and Designs has been temporarily shut down due to my frustration at not being able to code well.

We have all been there when we started, it can be frustrating when you don't feel like you are progressing.  All I can suggest is that you open a new thread and keep asking questions (not plugin related, but JavaScript in general, as I assume this is where you are struggling).  I'm more than happy to respond if I feel I can add something to your topic, and I'm sure others will do the same.

Try to find other people you can chat too who are also trying to learn, maybe find someone that can help guide you.  I've guided quite a few people over the years, and more recently a good friend of mine who knew absolutely nothing and is now working full time as a web developer (and he is very good at what he does).  Unfortunately I don't really enjoy that aspect of it anymore, I don't mind group chats though.

But yeah, keep asking questions no matter how stupid you may think it is, eventually things will just fall into place.  Try not to focus on making plugins, get the fundamentals of JavaScript down first.  While you can skip a lot of it and jump straight in with jQuery, later on down the road you will hit a wall if you don't know the basics.

Maybe a challenge every couple of days to test you (other people could take part as well, depends how many would be interested) would be good.  Start basic, and eventually move into jQuery and then plugins.  Could be fun to see the different ways people do things when they post their solution.

[Chris]

The best way to learn is to DO (or do not)
Failure is not an option but it is the chosen default when left unchecked
I find your lack of faith (in yourself) disturbing
Use the Google Luke and soon your skillz will be complete

[Lynx]

Oh, fudge! Now I've caused a disturbance in the Force.

The problem is not with doing - but doing and having it work. And the last thing I want is people blocking me for asking too many questions.

[Peter]

Nov 26, 2015 19:25:31 GMT -8 Lynx said:

Oh, fudge! Now I've caused a disturbance in the Force.

The problem is not with doing - but doing and having it work. And the last thing I want is people blocking me for asking too many questions.

Am pleased you got the reference in Chris' post lol.  I can just imagine people reading that post not knowing the Darth Vader quote and thinking... "how rude"

It doesn't matter if it doesn't work, it's all a learning process.  If you came away with learning something from a failed attempt, consider it as a win.  I think I learn best from failure, and it happens more often that you would think.   I've written prototypes in the past that failed multiple times, but I kept trying and trying, eventually I learned new things, and created what I wanted to create.

For example, the Post Composer plugin; that all started from me playing with the Audio API as I was bored one day.  I played around with it, wrote a few little prototypes (not plugins), they all failed, but I learned a lot from those failed attempts.  It led me to learning about octaves and frequencies, it took a few prototypes until I fully understood it as I knew nothing...

github.com/PopThosePringles/ProBoards-Post-Composer/blob/master/post_composer.js

When I started out (many years ago ), I got frustrated a lot of times, as things I created would not work, or just sucked big time.  Back then there wasn't the resources there are today, we had to rely on learning from each other.  Now days you have youtube, forums, sites and more to pick from.  The documentation for API's have improved greatly, a lot coming with examples.  A long time ago, it was very hard find content like that.

If people block you for asking too many questions, then that's their problem.  I really encourage you (or anyone) to ask questions.  I dare ya, open a new thread, start with 1 question, once you are happy that your question has been answered and you fully understand, post another.  Good thing about publicly doing this, is that you may get a few of us respond to your question, which means you may learn different things from different people.

 

[Chris]

hear hear!!
All persons having business before the code are admonished to draw near and read the preceding post!

[Lynx]

Okay - quick questions then:

On these parts of the code:

<div class="field1 lookup micro-profile">
<div class="field2 lookup micro-profile float-right">
<div class="results lookup miniprofile" style="width:458px">

Can I just leave out the lookup micro-profile and lookup miniprofile and have a CSS component for field1, field2 and results to control the styling, such as:

.field1 {
   color: #fff;
   background-color: #aaa;
}

so it's not calling (and possibly causing problems with) the micro-profile and miniprofile attributes for styling? I'd most likely rename field1 to something like rptr-field1 (similar renames for the other 2) so as to make sure there are no CSS conflicts as well. Given that, is it possible to set color and background color from the theme's current default text color and background (odd or even) color? If so, how are those referenced in the CSS component? I've thought it might be something like:

.rptr-field1 {
   color: @default_forum_text_color;
   background-color: @container_background_color_1;
}

Would that work?

Thanks!

[Chris]

Nov 27, 2015 9:55:06 GMT -8 Lynx said:

Okay - quick questions then:

On these parts of the code:

<div class="field1 lookup micro-profile">
<div class="field2 lookup micro-profile float-right">
<div class="results lookup miniprofile" style="width:458px">

Can I just leave out the lookup micro-profile and lookup miniprofile and have a CSS component for field1, field2 and results to control the styling, such as:

.field1 {
   color: #fff;
   background-color: #aaa;
}

so it's not calling (and possibly causing problems with) the micro-profile and miniprofile attributes for styling? I'd most likely rename field1 to something like rptr-field1 (similar renames for the other 2) so as to make sure there are no CSS conflicts as well. Given that, is it possible to set color and background color from the theme's current default text color and background (odd or even) color? If so, how are those referenced in the CSS component? I've thought it might be something like:

.rptr-field1 {
   color: @default_forum_text_color;
   background-color: @container_background_color_1;
}

Would that work?

Thanks!

Individual class names such as field1 and field2 are fine but it is generally a good idea to also have a shared class for when you want to apply properties that are shared across multiple but related elements. For example, if you wanted field1 and field2 to have the same background-color it would be easier and less work for both you and the css engine to just use the shared class of lookup. The even class is just such a shared class and is used by Proboards on posts and messages (and of course mini-profiles) and backed by the Less variables that you mentioned (e.g. posts_even_background_color and posts_background_color which are generally set equal to @container_background_color_2 and @container_background_color_1 respectively) behind the scenes.

Less variables such as @container_background_color_1 are however not available to plugins^[1]. If you create an element within your plugin and want it to blend in well with whatever the current theme colors are then you must instead add the appropriate classes to your created element to have it inherit the properties attributed to that class. The cautionary note is that this can also cause problems such as when I demonstrated the use of the mini-profile class to inherit the theme's properties attributed to that particular class, any plugin that then came along looking for .mini-profile without qualifying it perhaps with acknowledgement of an ancestor such as .left-panel could then find itself in trouble dealing with a mini profile that is where one should not be. This is the sole reason why I sometimes do an ancestor path instead of a single class query (e.g. $('.left-panel .mini-profile') or better yet $('.item.post .left-panel .mini-profile') instead of just $('.mini-profile') ) particularly if I've seen that class being use elsewhere, call it defensive coding.

[Peter]

Great point about ancestor paths. I'm guilty of not doing it in a lot of my plugins, even though I know it would save me problems down the road in the future. Something I will definitely change in my current plugins so they play nice with others.

[Lynx]

Okay, I haven't really got to working with ancestors yet (and I've no idea where to find the lookup class), so to be at least somewhat defensive in my coding so it plays nicely with others, could I do something like this:

Take these lines:

<div class="field1 lookup micro-profile">
<div class="field2 lookup micro-profile float-right">
<div class="results lookup miniprofile" style="width:458px">


and have them like this:

<div class="field1 msg-rptr-fields">
<div class="field2 msg-rptr-fields float-right">
<div class="results msg-rptr-results" style="width: 458px;">


and have in the CSS component:

.msg-rptr-fields {
   color: #000;
   background-color: #aaa;
}
.msg-rptr-results {
   color: #000;
   background-color: #fff;
}

That way, I've got a much higher chance of not using a class used elsewhere (I hope) and also allows for Admins to use the CSS classes for manipulation to better match their theme. Would that way be considered an acceptable alternative?