Automatic SyntaxHighlighter with Prettify - asp.net

Working on a school project where we have creating a forum based website. We are using PageDown and Prettify to handle the text.
but like it's now we have to use <!--?prettify?-->on the code to get it out nice and smooth, but are there some way we can tell the program to handle all <pre>tags from PageDown automatic with prettify?
Are there some disadvantage to have automatic SyntaxHighlighter?
1# Possible solution, but not what i had in mind:
You can add $("pre").addClass("prettyprint"); to javascript. This code will give every pre tag the prettyprint class, but this short code will not work in Markdown preview so for me this is only a 50% solution.
2# Possible solution on preview, but not user friendly:
I have found out that you can call a function prettyPrint(); to highlight all the <pre>tags with class="prettyprint". So if we combined solution on with this and add a setInterval()(or something else like .click) to make calls we will get something that work with Markdown preview. I believe this way is not user friendly because it's using alot of computer power (I think) and if you watch closely you can see a little flicker sometimes in the <pre> tags.
This is the code:
var timer = setInterval(prettytimer, 0);
function prettytimer() {
$("pre").addClass("prettyprint");
prettyPrint();
};
If someone wondering why there is no .removeClass() or hasClass() check, that's because .addClass() doesn't add same class twice.

3# solution i went for:
This is the solution i went for in the preview handler site and solution 1# on rest of the web-page. There might be some better ways but this way will give you the Stack Overflow feeling.
var timer;
//If the code button have been pressed {}
$("#wmd-code-button").click(function () {
clearTimeout(timer);
timer = setTimeout(prettytimer, 3000);
});
//when on key have been released inside textarea
$(".wmd-input").on("keyup", function () {
clearTimeout(timer);
timer = setTimeout(prettytimer, 3000);
});
//If `timer` reach 3000 (3 seconds) execute this
function prettytimer() {
$("pre").addClass("prettyprint");
prettyPrint();
};
If you are using pageDown Markdown then you don't have to make any changes to this code, just copy it inside your javascript file :)

Related

Using `within` in custom helpers

I'm using CodeceptJS and I'm trying to write a custom helper that asserts an text and clicks "OK". This dialog pops up as a iframe modal to consent with cookies.
If I write following steps in my scenario
I.amOnPage('/some-path');
within({frame: '#iframeID'}, () => {
I.see('Headline text for dialog');
I.click('OK');
});
// ...
...my test seems to work just fine.
But when I make an custom helper out of that and configure it properly so I can use it:
const { Helper } = codeceptjs;
class CookieConsent extends Helper {
consentWithCookies() {
const { Puppeteer } = this.helpers;
within({frame: '#iframeID'}, () => {
Puppeteer.see('Headline text for dialog');
Puppeteer.click('OK');
});
}
}
module.exports = CookieConsent;
...and use it as a step:
I.amOnPage('/some-path');
I.consentWithCookies();
// ...
...it doesn't seem to work as the consent dialog doesn't get clicked away as it was when implementing this directly in the scenario. According to some console.log() debugging the within callback doesn't get called at all. Console doesn't throw any errors about undefined within or anything suspicious.
I suspect that using within in a custom helper isn't working or I'm doing something wrong that I can't figure out from the documentation.
This warning at documentation doesn't really clarify when within is being used incorrectly, and using await doesn't help the problem.
within can cause problems when used incorrectly. If you see a weird behavior of a test try to refactor it to not use within. It is recommended to keep within for simplest cases when possible. Since within returns a Promise, it may be necessary to await the result even when you're not intending to use the return value.
iFrames can be a pain to work without when it comes down to automation. There are a number of factors that can make an iFrame unreachable to a framework such as cross-domain iFrames, commonly used for increased security on the content served.
Now to fix your issue, all you have to do is use switchTo() - Docs in CodeceptJS which is a function available for all helpers made available. The order should be
I.switchTo('your iframe');
..... some actions here;
I.switchTo(); // You do this so that you get out of the iFrame context when done

meteor - live code update to webpage?

I'm curious to know whether Meteor would be suitable for following, and how I would go about writing the code.
I'd like to create a webpage, where by the code in a specific "div" can be hotswapped on the fly to users currently looking at that page. (eg. the div contains some text, but then an image replaces it.) Ideally, the swap would be executed manually by the the webpage's admin through the click of a button, or some code fired off on the server or something. Regular viewers to the webpage would not be able to do this - they only see the live changes on the page.
real-life example:
live internet broadcast is off-air, therefore the "div" contains "off-air" text. live hotswap of code happens when broadcast goes on-air, and the viewers of the webpage now see the html5 broadcast player in the "div" instead. later it is swapped back once the broadcast goes off-air.
I'm completely new to the Meteor platform, so I consider myself a newbie :) Any help is appreciated.
You might better off by using a reactive div using data from a collection (I'm going to use an example with raw HTML but you might be better off implementing your own functionality with what content to display instead: i.e
Basically take advantage of reactivity over hot code swaps
Client side html code
<template name="home">
<div>
{{{content}}}
</div>
</template>
js code
if(Meteor.isClient) {
MyCollection = new Meteor.Collection("MyCollection")
Template.home.content = function() {
if(MyCollection.findOne()) {
return MyCollection.findOne().content
}
}
}
if(Meteor.isServer) {
MyCollection = new Meteor.Collection("MyCollection")
//Set an initial content if there is nothing in the database
Meteor.startup(function() {
if(!MyCollection.findOne()) {
MyCollection.insert({content:"<h1>Test content</h1><p>Test Data</p>"
}
}
//A method to update the content when you want to
Meteor.methods({
'updatecontent':function(newcontent) {
id = MyCollection.findOne()._id
MyCollection.update(id, {$set:{content:newcontent}});
return "Done"
}
}
You can update your content either in the mongo collection or with something like (in your web console, client side or server side javascript):
Meteor.call("updatecontent","New content",function(err,result) {
if(!err) {
console.log(result)
}
});
Which will update the code live when you use it.
I'm sorry it's quite long but the bulk of it is setting/updating the html. Its actually much nicer than a hot code swap which would refresh the user's page

jQuery UI Dialog behaves unpredictably

The jQuery UI dialog drives me up the walls. To the best of my understanding, here's how it works:
When you do $('#myDialog').dialog({...}), it copies the #myDialog element and moves it inside this bizarre widget thing at the bottom of your body tag. This is crazy! It will duplicate possibly unique DOM elements (with ids) when it does this.
So what I'm trying to do is make it behave in a predictable way when I refresh the HTML of the original element (#myDialog). If I do this dynamically, sometimes the dialog doesn't open any more:
http://jsfiddle.net/t67y7/3/
Or sometimes the dialog opens with the old HTML (because it's cached at the bottom of the page that way). What is up with this?
Since nobody seems to have any idea how to tame this beastly dialog, here's the best thing I've come up with to date. I'll accept any superior alternatives.
var original = $('#dialogId')[0];
var clone = $(original).clone().attr('id', 'dialogIdClone');
var saveHtml = $(original).html();
$(original).html('');
$(clone).dialog({
... // other options
open: function (){
// add any dynamic behavior you need to the dialog here
},
close: function(){
$(clone).remove();
$(original).html(saveHtml);
}
});
The purpose of this whole craziness is to keep the HTML of the original dialog unique on the page. I'm not really sure why this can't be the built-in behavior of the dialog... Actually, I don't understand why jQuery UI needs to clone the HTML to begin with.
I know this has been posted for a while, but a less extensive way to handle this issue would be:
$('#your-dialog').dialog({
... // other options
open: function (){
// add any dynamic behavior you need to the dialog here
},
close: function(){
}
});
$('#your-dialog').remove();
This is due to dialog widget wants to be able to control the display and will wrap the inner content of the original dialog then create a brand new one at the bottom of the body.
The draw back of this solution is that the dialogs have to be the first to be initialized to ensure all your 3rd party library widget will operate properly.
Why don't you just call $("#dialogId").dialog("destroy") on close function, like this:
$("#dialogId").dialog({
close: function() {
$(this).dialog("destroy");
// you may want empty content after close if you use AJAX request to get content for dialog
$(this).html('');
}
}
The destroy function will remove the decorated code, and your dialog element will not be duplicate next time you show the dialog.
I added a sample code to jsfiddle.net example.
You need to empty the dialog before opening it.
$("#dialogId").html('');
$("#dialogId").dialog({
close: function() {
$(this).dialog("destroy");
}
}

JavaScript puzzle to solve : window.confirm = divConfirm(strMessage)

Scenario is : old site which has lots of JS code already written. If user want to change all the alert messages to new age jazzy Div based alert which are very common using JQuery, YUI, Prototype... etc.
There are mainly tree JS dialogs
1. alert
To changes this its simple we just have to write new function which will show the div popup and show the message, after that override the window.alert
function showDivAlert(strMessage){
//div popup logic and code
}
window.alert = showDivAlert;
2. prompt
This too look easy to write function to accept the string and show the text box for input value. Now as return action is based on the click of "OK" button life is easy here.
function shoDivPromp(strMessage){
//div pop up to show the text box and accept input from the user
}
window.prompt = shoDivPromp;
3. confirm
Now above two were easy to override and modify the default dialogs but there is complication with the confirm.
However default JS confirm dialog stops JS execution and when user click OK or Cancel execution is resumed by determining the return value (true/false). But if we user div popup the execution is not stopped which is problem. We can still implement the confirm but in that case we have to bind methods for OK and CANCEL case which will be attached to OK and CANCEL button. With this function signature will be like.
function newConfirm(msg, fun OkAction(), fun CancelAction)
Now this is problem that this cant help me change the confirm dialog across the site as we did with alert();
Question
I am not sure whether its possible or not to achieve but i think can be using some JS pattern. So let me know if its possible.
Now this is problem that this cant help me change the confirm dialog across the site as we did with alert();
That's correct. It's not possible to reproduce the synchronous nature of the alert/confirm/prompt functions in native JavaScript. There is the non-standard method showModalDialog which can do it using a separate pop-up document, but it's not supported by all browsers and it's generally considered highly undesirable.
So the plug-in-replacement strategy isn't going to work. You are going to have to change every place you called these methods in the rest of the script.
The usual pattern is to do it using inline anonymous functions, to preserve the local variables using a closure, eg. replace:
function buttonclick() {
var id= this.id;
if (confirm('Are you sure you want to frob '+id+'?'))
frob(id);
wipe(id);
}
with:
function buttonclick() {
var id= this.id;
myConfirm('Are you sure you want to frob '+id+'?', function(confirmed) {
if (confirmed)
frob(id);
wipe(id);
});
}
If you need this to be preserved you would need to look at a further nested closure or function.bind to do it. If you have your call to confirm in a loop things get considerably more difficult.
Obviously you also have to ensure that critical global state doesn't change whilst the confirm box is up. Usually this risk is minimised by greying out the rest of the page with an overlay to stop clicks getting through. However if you have timeouts they can still fire.
All 3 methods actually stop js execution, not just the confirm, because they're all modal dialogs. Personally, I would try to keep everything as asynchronous as possible as modal dialogs prevent interaction with the current document.
Your best bet is to use callback functions from the new confirm popup as you suggested yourself.
I'm having a hard time understanding exactly what you want to achieve. It sounds like you want to do something like the following:
Run some javascript code
Display a "confirm" box
Wait until the ok button or cancel button is clicked
Continue code when user clicks ok, return when user clicks cancel.
The reason you want to do this is that overriding the function with something that makes use of callbacks would require rewriting each section of code that uses the confirm function. If you want my advice, I would go ahead and rewrite the code so that it performs asynchronously. There's no way you can delay script execution without locking up the document which includes the OK and Cancel actions of your dialog.
if you changed the roles Alert / Prompt / Confirm. slows the execution pending user interaction to run the following code.
Overriding these functions, the code continues its execution.
To achieve this you have to modify each part of the code and work as if you were with asynchronous functions.
Then you can use any plugin for windows as sexy-alert-box, and overwrite Alert / Prompt / Confirm
The function signature would simply be:
function newConfirm(msg, okAction, cancelAction);
and would be used as:
function newConfirm(msg, okAction, cancelAction){
var ok = doWhateverPromptIsNecessary();
if (ok) {
okAction();
} else {
cancelAction();
}
}
That is, to pass function "pointers" in to a function as arguments, simply pass in the function name without the (). The function signature is the same.

Postpone Postback For 3 Seconds?

I have a usercontrol with a couple of drop downs Lists and a button, I want the user to click the button (Which response.redirects depending on the selection in the DDL's).
Now instead of redirecting straight away, I want to display a little loading icon for 3 seconds and then redirect... Has anyone done anything like this?
An artificial delay where none is needed is kinda lame. What you can do instead is on submission of your form display your throbber. I use the following on a document upload form where large media files are being posted.
<script type="text/javascript" id="PreJavaScript">
function NUsubmit(){
document.getElementById("uploadFormInputs").style.display = 'none';
document.getElementById("progressBar").style.display = 'block';
return true;
};
function init() { document.getElementById("UploadFormObject").onsubmit = NUsubmit; };
window.onload = init;
</script>
If I remember correctly, in some versions of IE the animated gif didn't play but it worked fine in IE6+ and FireFox.
This way if the postback is quick they never see the throbber but if it takes a while they see it and it gives them the sense that something is happening.
You can perform delays with the setTimeout() function in javascript.
setTimeout(function() { alert('After 5 seconds.'); }, 5000);
You're probably going to need to override a couple things in your Javascript and use a "setTimeout" to delay the loading.
<script type="text/javascript" >
var __handleSubmit = theForm.submit;
theForm.onsubmit = function() {
alert('loading'); //Show your message here
window.setTimeout(function() {
__handleSubmit();
}, 3000);
}
</script>
You might want to play with a bit more... this is may not work for all instances since I've never done it.
If the delay is simply for "aesthetics", to make it appear it is working, then I'd recommend against it - programmers appear to be the only people that think loading bars are cool :)
Looks like you should implement this page using AJAX. You can place a progress indictor on your page to alert the user that a long running process is taking place.
I got this working by using
System.Threading.Thread.Sleep(4000);
In the postback

Resources