I have an ExpressionEngine plugin wrapped in a simple {if} conditional:
{if logged_in_member_id == segment_2}
{exp:external_entries:insert table="whatever" debug="n"}
{insert:member_id}{segment_2}{/insert:member_id}
{/exp:external_entries:insert}
{/if}
The problem is that the plugin code executes regardless of whether the conditional is met or not.
For example, even if segment_2 does not match logged_in_member_id, the plugin still executes.
My understanding is that simple conditionals are evaluated before plugins. What am I doing wrong?
Related
In an Android Studio (and presumably ANY) gradle file, the following code works:
task build {
}
And one minor change causes a complete meltdown:
task build
{
}
This has come up in other threads before, but in the context of fixing the build files. My question is why can't gradle/groovy be made to deal with either bracing style? Many other languages cope just fine with it, so what's the big deal here?
It's actually all right there in the error message:
build file '.../build.gradle': 80: Ambiguous expression could be a parameterless closure expression, an isolated open code block, or it may continue a previous statement;
solution: Add an explicit parameter list, e.g. {it -> ...}, or force it to be treated as an open block by giving it a label, e.g. L:{...}, and also either remove the previous newline, or add an explicit semicolon ';' # line 80, column 1.
Because of a Groovy syntax sugar to make methods with a lambda as the last parameter look line language constructs, the following code blocks:
task build {}
task build2(type: Copy) {}
are equal to their more regular form:
task build({})
task build(type: Copy, {})
Now, you do not really want those curly braces there to delimit a regular code block, but a Groovy lambda, which should be passed as a parameter to the build method.
Yet from the looks of it, Groovy can't really decide if it really is a lambda being passed as a parameter to the method in the previous line or an unrelated code block when you put a newline in between. And there you go, an ambiguousness as described in the error message, right there.
Following the advice in the error message, you can also use the following syntax instead of the one where you are escaping the new-line character:
task build
{ ->
}
Finally, the task keyword used to invoke the dynamic method (named build in your example) is not Groovy specific, but a Gradle DSL feature.
In case anyone reading this is wondering, the work-around is simple enough.
task build \
{
}
I was just wondering as to the "why"...
I see that in the cobertura-maven-plugin, I can configure my instrumentation with both excludes and ignores. What is the difference between these two?
Really sorry, but parroting the horrible documentation is not helpful. You quoted:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
This inconsistent paragraph starts by stating "...to ignore certain classes by passing in 'ignore' regular expressions.", then a second sentence later, "This will ignore any calls to any method that matches the ignore regular expression."
Well, so which is it? Does "ignore" ignore classes or methods? The command-line reference seems to imply ignore is ignoring a line of code based on RegEx matching (I wish that was true):
None of these interpretations works for <ignore> in the maven plugin.
Experimentally I have found that <exclude> is the way to exclude at the class-level. I have not found a way to exclude at a granularity less then class. However, what they also don't tell you is that <exclude> expects a relative filesystem path, not a Java package.class expression, which means <exclude> expects e.g. one/two/three/Myclass.class, rather then "one.two.three.Myclass".
Ignore and exclude really function nothing alike. Exclude will remove a file from Cobertura's scan. Ignore will remove all usages of a class from contributing to line coverage.
Consider the following code snippet:
public class Foo {
public void someMethod() {
Bar bar = new Bar();
}
}
If you configure <exclude>Foo.class</exclude>, then the entirety of the Foo class will not show up on your reporting.
Semi-confusingly, if you configure <ignore>Foo.class</ignore>, then Foo will still show up on your reporting, but uses of Foo in other classes will be ignored.
If you configure <ignore>Bar.class</ignore>, then the scan of Foo will ignore the line in which Bar is initialized.
To really make that stick, let's talk about why you would use ignore. Let's say that there is an object (such as a Logger) that you do not want to show up in the code coverage scan of any classes. Ignore allows you to do this.
The maven plugin does not contain any documentation for this configuration options (but they are included in the docs). The ant cobertura doc contains the following documentation:
You can tell Cobertura to ignore certain classes by passing in "ignore" regular expressions. The ignore pattern can be any valid perl 5 regular expression. This will ignore any calls to any method that matches the ignore regular expression. It will NOT skip over these classes during instrumention. To exclude classes from being instrumented, either exclude them from your fileset or use the alternative method below and specify an excludeClasses pattern.
See also: https://github.com/cobertura/cobertura/wiki/Ant-Task-Reference#cobertura-instrument-task
I try to hide the getPage [[+pageNav]] Placeholder if there is no pagination. But I can't do the following.
[[!+pageNav:notempty=`<ul class="overview__pagination">[[!+pageNav]]</ul>`]]
Does someone know how I can hide the element with an apropriate output filter? (without own extra snippet). I also tried the following and some other (not likely to work variations).
[[!+pageNav:isnot=``:then=`<ul class="overview__pagination">[[!+pageNav]]</ul>`]]`
Are you calling that code in a chunk that is cached?
Otherwise i've experienced this aswell and it seems custom placeholders sometimes behave that way, it's probably due to the fact that they actually have some unprocessed value during the IF computation but when it's actually output you see nothing. Or that the value is somehow "null" instead of "" while modx output filter might do a strict comparison.
If you're not calling it in a cached chunk or part of code, i suggest first trying with another getPage placeholder such as pageCount or total.
Like:
[[!+pageCount:gt=`1`:then=`<ul class="overview__pagination">[[!+page.nav]]</ul>`]]
If that still doesn't work, a last resort in the form of a simple snippet will always solve it, like:
[[!outputPagination? &total=`[[+total]]` &limit=`XX` &output=`<ul class="overview__pagination">[[!+page.nav]]</ul>`]]
In snippet:
if ($total > $limit) {
return $output;
}
Shouldn't it be...
[[!+page.nav:notempty=`<ul class="overview__pagination">[[!+page.nav]]</ul>`]]
Well, there is a much more easier way to do it than in the first answer. It's like TheMistaC says, even if my answer is a lot easier:
[[!+page.nav:notempty=`
[[!+page.nav]]
`]]
I use it to display a list of articles with getResources, so I know this works fine.
Consider the following sample codes:
1.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)
? 'yes'
: 'no';
console.log(IsAdminUser);
2.Sample
var IsAdminUser = (User.Privileges == AdminPrivileges)?'yes': 'no';
console.log(IsAdminUser);
The 2nd sample I am very comfortable with & I code in that style, but it was told that its wrong way of doing without any supportive reasons.
Why is it recommended not to use a single line ternary operator in Node.js?
Can anyone put some light on the reason why it is so?
Advance Thanks for great help.
With all coding standards, they are generally for readability and maintainability. My guess is the author finds it more readable on separate lines. The compiler / interpreter for your language will handle it all the same. As long as you / your project have a set standard and stick to it, you'll be fine. I recommend that the standards be worked on or at least reviewed by everyone on the project before casting them in stone. I think that if you're breaking it up on separate lines like that, you may as well define an if/else conditional block and use that.
Be wary of coding standards rules that do not have a justification.
Personally, I do not like the ternary operator as it feels unnatural to me and I always have to read the line a few times to understand what it's doing. I find separate if/else blocks easier for me to read. Personal preference of course.
It is in fact wrong to put the ? on a new line; even though it doesn’t hurt in practice.
The reason is a JS feature called “Automatic Semicolon Insertion”. When a var statement ends with a newline (without a trailing comma, which would indicate that more declarations are to follow), your JS interpreter should automatically insert a semicolon.
This semicolon would have the effect that IsAdminUser is assigned a boolean value (namely the result of User.Privileges == AdminPrivileges). After that, a new (invalid) expression would start with the question mark of what you think is a ternary operator.
As mentioned, most JS interpreters are smart enough to recognize that you have a newline where you shouldn’t have one, and implicitely fix your ternary operator. And, when minifying your script, the newline is removed anyway.
So, no problem in practice, but you’re relying on an implicit fix of common JS engines. It’s better to write the ternary operator like this:
var foo = bar ? "yes" : "no";
Or, for larger expressions:
var foo = bar ?
"The operation was successful" : "The operation has failed.";
Or even:
var foo = bar ?
"Congratulations, the operation was a total success!" :
"Oh, no! The operation has horribly failed!";
I completely disagree with the person who made this recommendation. The ternary operator is a standard feature of all 'C' style languages (C,C++,Java,C#,Javascript etc.), and most developers who code in these languages are completely comfortable with the single line version.
The first version just looks weird to me. If I was maintaining code and saw this, I would correct it back to a single line.
If you want verbose, use if-else. If you want neat and compact use a ternary.
My guess is the person who made this recommendation simply wasn't very familiar with the operator, so found it confusing.
Because it's easier on the eye and easier to read. It's much easier to see what your first snippet is doing at a glance - I don't even have to read to the end of a line. I can simply look at one spot and immediately know what values IsAdminUser will have for what conditions. Much the same reason as why you wouldn't write an entire if/else block on one line.
Remember that these are style conventions and are not necessarily backed up by objective (or technical) reasoning.
The reason for having ? and : on separate lines is so that it's easier to figure out what changed if your source control has a line-by-line comparison.
If you've just changed the stuff between the ? and : and everything is on a single line, the entire line can be marked as changed (based on your comparison tool).
I trying to find out if one string contains another. But, unfortunately, fn:contains function is case-sensitive. Are there are any ways to make it case-insensitive?
I tried to put both into one case:
fn:contains(car.color.toLowerCase(), smartBean.txt.toLowerCase()) ? 'true' : 'false'
But it didn't work due to method's brackets. I also can't use f:to-upper inside f:contains function.
There's a fn:containsIgnoreCase(). Just use it instead.
#{fn:containsIgnoreCase(car.color, smartBean.txt)}
By the way, your failed toLowerCase() attempt should have been done as follows:
#{fn:contains(fn:toLowerCase(car.color), fn:toLowerCase(smartBean.txt))}
Using toUpperCase() works as good as well:
#{fn:contains(fn:toUpperCase(car.color), fn:toUpperCase(smartBean.txt))}
Perhaps you just made an EL syntax error.
Note that the ? 'true' : 'false' part is completely superfluous as that's already returned by the function.
For those just finding this, #BalusC's answer is correct - but structure has changed, see just fn:upper-case, fn:lower-case - don't see the ignoreCase option anymore but if you cast it one way or the other to compare, it will work.