I know if I pass {{variable}} (like a {{event.text}}) in args field of action form works fine.
But, when I try concatenate this variable with a another String, this not work.
Result in {{state.api_url}}/users string, and I need http//myapi.com/users
Is it possible?
I may have an extremely kludgy workaround for this based on bad javascript.
I was looking to iterate a temp variable downwards. I did the assignment in the raw code box for a transition
Good code like temp.variable==1 would be a true/false test.
But just using one equals sign performs the assignment.
So temp.variable=temp.variable-1 in the raw code box subtracted one from my (numeric value) variable.
This seems to return False for the purposes of the transition so it doesn't matter where you point it as long as it's in the chain.
It seems to work for me, anyway.
I'm properly not sure what your code would look like, perhaps you make a new variable then do a transition with
temp.variable_you_just_made=state.api_url+'/users'
then call that variable doing your url thing?
[Looking around I come to suspect the correct thing would be to make a new action https://botpress.io/docs/10.0/getting_started/trivia_actions/ but I am new to all this]
Related
I'm learning how to integrate Javascript into HTML, and I had an idea for some odd code. I can't say for certain if there is something wrong with it.
My goal was to create a counter that is displayed on the page that starts at 1 and increases every time a function is called.
My original code was something like this:
<p id="counter"></p>
<script>
var turn = 1, turn_counter = document.getElementById('counter');
turn_counter.innerHTML = turn;
function increase() {
turn++
turn_counter.innerHTML = turn;
}
</script>
The variable turn would keep track of a number, and turn_counter would keep track of the <p> tag. The contents of this tag were then set to turn. When the function increase() was called it would increment turn and then adjust the tag to match.
However I realized there was a potential simpler solution:
<p id="counter">1</p>
<script>
var turn_counter = document.getElementById('counter');
function increase() {
turn_counter.innerHTML++
}
</script>
This writes "1" inside the <p> tag and then sets the variable turn_counter to that tag. Then whenever the increase() function is called it simply increases the number inside the tag.
While both solutions work, I feel like there must be some problem with using the second one. Something about storing a variable inside an HTML tag doesn't feel right. So are there any problems with the second solution?
(Also if there are any better ways of doing this I'd be open to them. I'm still very new to this.)
While with the first solution you are actually storing a variable in Javascript in the second example you are making use of Javascript "quirks" but it's probably not what you wanted.
When you read the innerHTML of the counter div, Javascript finds a string number, as "1" but since "1" is shallow equal to 1, Javascript tries to apply mathematics to it and does what you asked.
Is it working? Yes.
Is it bad? Also yes.
But why is it working? It's working because of Javascript's type coercion and type casting based on that.
Why is it bad? It's not bad because of type coercion, it's not good because of the fact that you are saving your application state on the UI layer which is doable but not a good op.
You are not storing a variable in this case, you are just making use of Javascript weird behaviors. You could potentially parse the innerHTML to turn it into a number but it's yet far from a solution as you wouldn't properly save "state" for your javascript application, which is where to logic resides!
You could see HTML as the UI layer (unstyled) but you want to keep the logic (like variable declaration and usage) inside Javascript.
As proposed by #GrafiCode in the comments, you could
const whatAmI_1 = div.innerHTML + 1
const whatAmI_2 = div.innerHTML++
typeof whatAmI_1 // string, 11
typeof whatAmI_2 // number, 2
This is because the increment operator (++) parses the string, casts it to a number and applies the necessary incrementation while the + 1 is seen as a concatenation of strings as the second value (+1) gets parsed and casted to string by Javascript.
#Wiktor Zychla noted that maybe the word "quirks" is not explicative enough about the choices made by Javascript. Type coercion is not something bad or wrong, it's part of Javascript and if you know what it is and how to use it, you can do a lot of things.
I am still new a Javascript tried earching and tried the development tool in Chrome, too see if I could find the problem.
Working in Intellij IDEA 13, Java, javascript and xhtml.
My problem is that I have a piece of javascript, then in IDEA when moused over, says that
Expression Expected
the javascript code looks the following
<script type="text/javascript>
function nameOfFunction(){
if(#{trendAnalysisLocationReportController.model.showTargetLine}){
this.cfg.series[this.cfg.data.length-1].pointLabels = {
show: false
};
}
}
<\script>
the method in the if sentence is a java method with a boolean return value.
the error is shown when hovering
'#{'
if Had a look at the following questions, before :
Expected Expression
boolean in an if statement
But didnt get me a solution.
what Iam I doing wrong ?
It looks as though the problem is the part that you've got within the #{...} block. Without knowing the context, it's hard to be sure, but is this something in a view/JSP page that's supposed to be replaced with a property at runtime? The if block will expect the part inside the brackets to be a boolean value, so if that's rendered to either 'true' or 'false' it would execute at runtime but would likely show the error you're seeing in your IDE as it's not actually a valid piece of JavaScript. If, on the other hand, you're expecting to be able to call your Java method/property from your JavaScript code, you're going to need to do something that requests that value from the server-side code - AJAX or similar.
Also worth noting that we can't see what this.cfg is supposed to represent. If that's your entire script block, then there's nothing that defines the cfg object within the current scope.
One last thing, you should change the <\script> end element to as it won't be understood properly by some browsers.
I am trying to make a graph of a simple function y=k*x+b.
A user enters a function into the input field, for example:
1/3*x+3
and when he/she clicks the submit button, a JavaScript function is supposed to take this input value as an actual calculation sequence and assign a variable to it (I only need to get certain y values here, so the x variable has its limits):
for (x=1;x<=40;x++)
{
result = window.document.menu.inputFunction.value;
}
The above code doesn't work. No wonder why - I am just a beginner at this. However, is this really harder than it looks, or am I missing out something? I considered trying regular expressions for this at one point, but my head hurts by even thinking about using them.
Any ideas?
You could eval it:
result = eval(window.document.menu.inputFunction.value);
There are obviously some limitations to this approach:
The user must enter a valid javascript expression
The user must use x as variable name because that's what you are using in the loop
The code is vulnerable because the user can enter and execute any javascript expression he likes
For a more robust solution you might consider using a javascript mathematical expression evaluator.
if (1) {
google_conversion_value = 1;
}
What is the meaning of the above statement? I mean, this looks like it will always execute so why bother with the if statement?
updated: one reason might be remnants of scripting on the server side. Any other ideas?
updated2: could as easily change the value of the assignment without bothering with the if statement, no?
There are two likely explanations:
It's a leftover from debugging.
The file containing this code is generated dynamically and the original sourcecode contains something like if(<?php echo $some_stuff_enabled; ?>)
However, in the latter case it would have been cleaner to output that code block only if the condition is met - but maybe it's used in some crappy template engine that just allows replacements but no conditionals...
I've seen this before, and I've always assumed it was a remnant of some old condition that was no longer needed, but never removed. I can't see any actual reason to do something like that otherwise.
Potentially because the person writing the code wanted an easy way to turn it off and on again, this is especially useful if there is a lot of code inside the block (not the case here).
Another possibility is that the original programmer couldn't be bothered writing the logic or, more likely, it hadn't been specified so the "if" was left as a placeholder.
More than likely left in from a debug release or something similar. You're right, it will always execute. It could also have been done like this so that it can be easily enabled / disabled by setting the if to 0. Perhaps the developer intended to use it as a flag somewhere else in the code?
actually, this happens when the "if" condition is driven from server, so instead of doing the right thing and not produce the script when the condition is false, they do something like this:
if (<% if (my_server_condition) then Response.Write("1") else Response.Write("0") %>){
// code goes here
}
Perhaps the if statement used to check for a legitimate conditional, and then someone replaced it with a truthy value for testing/debugging/etc.
You're right, it will always execute because 1 is truthy. I would go through your source control history and investigate that line to see if it used to contain a real conditional. If the conditional was always 1, then it's likely a debugging statement. Otherwise someone might have meant for it to be a temporary change, and may not have meant to check that in (which could be bad).
I'm not sure where this code is from, but as you indicated it will always execute. As for why you'd do this, there are times where you want to see what the result of branch code would be, without having to setup an environment. In this case you can comment out the actual value and replace it with if(1) instead for testing:
// if( ... some hard to achieve condition )
if (1) {
// Now you can see what happens if this value is set quickly
google_conversion_value = 1;
}
Of course the problem with this is that it's sometimes easy to forget to remove the if(1) and uncomment the proper condition.
This is actually the javascript recommended by Google on http://support.google.com/adwords/bin/answer.py?hl=en&answer=1722054#nocomments (click on Step 2 for the sample HTML)
I'm going berserk with this. Although http://www.prototypejs.org/api/element/insert is far from being the best documentation page ever, I struggle with a really stupid simple implementation:
$('account').insert({'top':new Element('a')});
I also tried with a plain HTML string instead of new Element(a), but it doesn't change anything... Can you spot what's wrong with what I'm doing ?
Prototype returns null from $("foo") if no element with "id" value "foo" is on the page. If you're using the "id" value "account" on multiple elements, anything might happen, so don't do that. Otherwise make sure there's an element with "id" value "account" on the page when that code runs.
In JavaScript, the semicolon terminates a statement. You don't want to terminate the statement there, you wanted to call .insert on the result of $('account'), so don't put a semicolon there.
According to the documentation you linked, you're also missing a set of curly braces and some quotes.
$('account').insert({'top': new Element('a')});