Wayfinder

I noticed that this wayfinder call doesn’t seem to work in 0.9.7.



It produces nothing at all.

It’s because of the missing backticks. I don’t think this restriction was there in 0.9.6 so (unless I’m wrong) this might bite some people. I don’t know if this is Wayfinder or the core. I don’t have strong objections to being strict and requiring backticks, but we might want to warn people if every parameter will require them and, if they aren’t *always* required, it may cause some trouble for users.

I believe they’re going to always be required now, but I’m sure Jason will confirm shortly.

Quote from: rthrash at May 01, 2008, 10:54 PM

I believe they’re going to always be required now, but I’m sure Jason will confirm shortly.

I believe the rule is they are required if you want to include whitespace in your tags, but this sure seems like a trivial example. I’ll look into it; BobRay, can you do the honors and post a task in Jira for this one?

I think they should always be required. Here’s why:

If not required, this would not be possible:



With backtick:



Plus I’m a big fan of clean code with good standards.

I’m generally for bulletproof parsing that forgives user errors unless there’s a good reason to do it some other way but I wouldn’t mind requiring backticks.

IIRC, one of the first things that bit me in MODx was that this form didn’t work because of the spaces around the equals sign:



I don’t know if this will work in 0.9.7 but I think it probably should (though this is certainly no time to be messing with the parsing code).

Bob

Quote from: OpenGeek at May 01, 2008, 11:51 PM

Quote from: rthrash at May 01, 2008, 10:54 PM

I believe they’re going to always be required now, but I’m sure Jason will confirm shortly.

I believe the rule is they are required if you want to include whitespace in your tags, but this sure seems like a trivial example. I’ll look into it; BobRay, can you do the honors and post a task in Jira for this one?

Done (MODx-122). I hope my explanation of the issue makes sense.

Thanks for those observations and report Bob... I think your suggestion for as bulletproof as possible parser is sage advice.

Quote from: BobRay at May 02, 2008, 12:30 AM

I’m generally for bulletproof parsing that forgives user errors unless there’s a good reason to do it some other way but I wouldn’t mind requiring backticks.

IIRC, one of the first things that bit me in MODx was that this form didn’t work because of the spaces around the equals sign:

[[Snippet? &parameter = `hello`]]

I don’t know if this will work in 0.9.7 but I think it probably should (though this is certainly no time to be messing with the parsing code).

It just occurred to me that requiring backticks might make it easier to accept this form so it might be a worthwhile tradeoff.

Now that eval() is gone, do we have the abilitiy to do some error checking and helpful error messages on snippet parsing to point out things like missing ?, &, and ` characters?

I don’t think the new parser is all that sensitive to whitespace outside of the backticks, hence you can split a call amongst multiple lines if memory serves me correct. Nice for reading some of those potentially crazy ditto or ajaxsearch configs. For example:

Quote from: rthrash at May 02, 2008, 11:19 PM

I don’t think the new parser is all that sensitive to whitespace outside of the backticks, hence you can split a call amongst multiple lines if memory serves me correct. Nice for reading some of those potentially crazy ditto or ajaxsearch configs. For example:

[[Foo?
  &parents=`1,2,3,4`
  &param=`Look at the cool extra-special characters & stuff = niceness, eh?`
  &param2=`[[another?snippet=`even with cached inside cached`]]`
  & question = `for Jason: will this line work?`
]]    

It should not care about the whitespace, but I’m not positive about that last line at the moment; feel free to test it and report the results in JIRA if it does not. It can likely be remedied easily if it can’t handle it currently.