I understand how to add
<%= debug(params) if Rails.env.development? %>
but why will
<%= debug(params) if Rails.env.test? %>
not do any good?
ActionView::Helpers::DebugHelper#debug "returns a YAML representation of object wrapped with <pre> and </pre>", and putting it between <%= %> on a page displays it, so it can help when debugging through the browser as you always have a page open.
In a testing environment though, you're mostly running 'headless' (not using a browser), so you've got nothing to display since you don't have a page open.
If you want to debug your tests during runtime (do stuff like see what values are being assigned to your variables during your tests etc), then you can absolutely do that with gems like Pry and Byebug.
Related
I have my site package extension toolbox with a lot of custom ViewHelpers. For not violating DRY rule I registered my own namespace (with global namespace import tip) for recognizing it within Fluid instead placing at the beginning of each template as usually in typo3conf/ext/toolbox/ext_tables.php and in general that works:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']['toolbox'] = ['BIESIOR\Toolbox\ViewHelpers'];
I can (or rather could) use my VH's like <toolbox:someViewHelper />, however after moving page from development to production (the same machine, just switched domains) suddenly I get an exception like:
TYPO3Fluid\Fluid\Core\Parser\UnknownNamespaceException
Fluid parse error in template Standard_action_Orangeheader_2c41396366318874342b894b22eff7acb311cc0c, line 2 at character 1. Error: Unknown Namespace: toolbox (error code 0). Template source chunk: {toolbox:containerEscape(condition: data.tx_mask_escape, start: 'true')}
What's frustrating this problem disappears when I'm logged to BE as an admin and preview the FE in the same browser, as fast I'll logout from BE and/or visit required FE page in another browser, the exception comes back.
As mentioned during development this problem didn't occur, after logout.
ViewHelper is used in page's template included in main TypoScript with FLUIDTEMPLATE cObject.
Had somebody such weird behaviour?
Use ext_localconf.php instead of ext_tables.php for it.
Not sure, but I think ext_table.php is Backend End (BE) context only, but you need the ViewHelper in the FE Context.
I've spent more time on this than I care to admit but was hoping for some help in understanding the cause of the problem. I have a basic HTML web resource in Dynamics 365 (v9.1.0.9228) and in order to get the global context I must include the following:
<script src="ClientGlobalContext.js.aspx" type="text/javascript"></script>
https://learn.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/getglobalcontext-clientglobalcontext.js.aspx
The problem is that when I do... the Chrome debugger loses its place in the document. The execution stops at the breakpoint(s) but the current line is not highlighted this means no way to step into/over the lines or indeed know what line we are on at any given point. I can see however that the code is being executed due to my output to console (See code in footer).
I have tested this across:
Multiple D365 online instances (v9.1.0.9228)
Multiple development machines running Chrome (v77.0.3865.90)
Literally stripped back the code to very basic HTML. Interestingly, this issue does not occur in IE? The only workaround I have found is rather than having inline JS within the head tags place it a separate file instead and reference from the HTML web resource, Chrome then seems to have no issues in stopping on right line and highlighting the correct line as we debug BUT only functions within that library. If the HTML web resource has inline script the issue will still be present within that scope.
head
<script type="text/javascript" src="ClientGlobalContext.js.aspx"></script>
<script type="text/javascript">
function registerEvents() {
debugger;
console.log("in registerEvents v2.0.3");
testButton = document.getElementById("test");
testButton.onclick = test;
}
function test() {
debugger;
console.log("in Test v2.0.3");
}
</script>
body
<script type="text/javascript">
registerEvents();
</script>
<p>In chrome debugger v2.0.3</p>
<button id="test">Test</button>
I would like to understand if I am doing something wrong here as it seems to be a bug within Chrome DevTools itself given this works on all other browsers when debugging? The actual code here is almost irrelevant as the issue occurs whenever "ClientGlobalContext.js.aspx" is referenced, if we comment out that line the Chrome debugger works as expected.
My page elements should appear in all browsers as follows:
I can only achieve this in IE11 by having the dev tools open during page load, otherwise the page generates as the following:
Summary
no rounded corners on box elements
no column alignment (bootstrap class "col-lg-2" on
all label elements)
Legend formatting not added
general alignment off
no smooth accordion transition - open or closed
This issue is only with IE11, the site works in chrome, firefox and even Safari without any additional plumbing. I have found some IE fixes on SO, but so far none of them have worked:
*.html - add meta information to use Edge engine
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<html>
<head>
<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
<![endif]-->
... html continues with rest of head
*.js - to prevent undefined console from blocking processing
if(!window.console) {
console.log(item);
}
I have been sure to use Ctrl F5 when reloading the page for testing, and have also restarted devmode to see if that makes a difference. I have also confirmed that the site is not running in compatibility mode by looking in the compatability settings.
Looking through the logs I can see that when the page loads with dev tools closed, the binding is carried out using user.agent=ie8, whilst with devtools open, the binding property is user.agent=gecko1_8. I thought IE11 should always use the gecko1_8 permutation - why could this not be happening?
(using GWT Version 2.7)
Not sure if this will be of any help.
We are using GWT (2.8, but I think it also worked with 2.7 in the past).
With GWT-Bootstrap3 (https://github.com/gwtbootstrap3/gwtbootstrap3) without any problems in IE11. I am not sure you are using the same bootstrap library ?
Anyway. We added the following line in our html file (as the first line of the head tag) :
<meta http-equiv="x-ua-compatible" content="IE=10">
I can not really remember how I came up with this line, but the version history states : "It is now possible to use IE11 in compatibility mode"
So it has to do something with fixing something in IE-11, using GWT and bootstrap 3 :-)
hello friends I have a big problem with internet explorer, I made a date validation using "select" with jquery, in Mozilla and crome works, but IE does nothing. Please I need help!
Your JS code calls for elements that aren't created in IE version less than 7 - thus it does nothing. See below:
<!--[if lt IE 7]>
<script type="text/javascript">
document.createElement("#date-star-month");
document.createElement("#date-star-year");
document.createElement("#date-finish-month");
document.createElement("#date-finish-year");
document.createElement("#date-star-month option");
document.createElement("#date-star-year option");
document.createElement("#date-finish-month option");
document.createElement("#date-finish-year option");
document.createElement("year_star");
document.createElement("year_finish");
</script>
<![endif]-->
This will not work in IE older than 7 - tested on 9, didn't work, until I ran IE9 in quasi-IE7 mode.
Additional pointers
Would be much easier to answer your question if you would be more specific.
Adding your code was a good move, do that from the start.
Too bad you didn't:
let us know what the validation function is supposed to do
on what browsers (with their versions) have you tested this
Also, if you state your intentions (why do you need that data validation, what it must do, etc.) you can get extra tips to achieve this in other (maybe better or easier) way.
I've encountered what seems like a chicken & egg problem, and have what I think is a logical solution. However, it occurred to me that others must have encountered something similar, so I figured I'd float it out there for the masses.
The situation is that I want to use dojo's addOnLoad function to queue up a number of callbacks which should be executed after the DOM has completed rendering on the client side. So what I'm doing is as follows:
<html>
<head>
<script type="text/javascript" src="dojo.xd.js"></script>
...
</head>
<body>
...
<script type="text/javascript">
dojo.addOnLoad( ... );
dojo.addOnLoad( ... );
...
</script>
</body>
</html>
Now, the issue is that I seem to be calling dojo.addOnLoad before the entire Dojo library has been downloaded the browser. This makes sense in a way, because the inline SCRIPT contents should be executed before the entire DOM is loaded (and the normal body onload callback is triggered).
My question is this - is my approach sound, or would it make more sense to register a normal/standard body onload JavaScript callback to call a function, which does the same work that each of the dojo.addOnLoads is doing in the SCRIPT block. Of course, this begs the question, why would you ever then use dojo.addOnLoad if you're not guaranteed that the Dojo library will be loaded prior to using the library?
Hopefully this situation makes sense to someone other than me. Seems like someone else may have encountered this situation.
Thoughts?
Best Regards,
Adam Rice
You're doing it correctly. External Javascript files are loaded and executed synchronously in order, so by the time it reaches your dojo.addOnLoad( ... ); Dojo has loaded. Use dojo.addOnLoad instead of window.onload for two reasons:
it fires earlier, because it utilizes DOMContentLoaded
it handles asynchronous loading of dojo.require by postponing the execution until all required scripts have been read
Explained in DojoCampus as (dojo.addOnLoad):
dojo.addOnLoad is a fundamental aspect
of using Dojo. Passing addOnLoad a
function will register the function to
run when the Dom is ready. This
differs slightly from document.ready
and body.onload in that addOnLoad
waits until all dojo.require() (and
their recursive dependencies) have
loaded before firing.
This might have nothing to do with your problem, but ive just had a case where I had the same symptoms. For me everything worked fine for Firefox, Chrome etc, but not IE8.
I was getting what looked like dojo not being loaded, an error in IE8 saying that dojo was undefined (but not all the time) and i could strip everything down to just style sheets and importing dojo and still get the error.
I was running a local google app engine development server. This looks to be based on pythons SimpleHTTPServer which in turn uses SocketServer.BaseServer. This has BaseServer.request_queue_size which defaults to 5 - i couldn't find anything in app engine which overrode this value so i guess the development google app engine server has an upper limit of 5 connections.
Using regedit and going to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
“MaxConnectionsPerServer”=dword:00000010
“MaxConnectionsPer1_0Server”=dword:0000010
This shows that IE was going to try and open up to 10 simultaneous connections. I edited these two keys and made them 2 and restarted the computer, the problem went away.