MODx Recursive Parser - Beta 2a

I suppose you could replace =’ and =" with =` and ’ & with ` & and ’ ] and ’] with `] ...that’s an interesting thought indeed Mr. Doze.

It’s possible to use `, ’, and " but IMO " would require a bit more processing since we would have to detect &quote;

I can make the parser work with both ` and ’ but why bother when users will be able to create parser tags using a Tag Builder? The other reason is that this would also add a bit more work to the parser’s AI.

Quote from: xwisdom at Jul 13, 2006, 01:08 AM

....add a bit more work to the parser’s AI.

Your parser is now fully sentient and Turing complete? Crap, must have missed that thread

Quote from: vbrilon at Jul 13, 2006, 01:24 AM

Your parser is now fully sentient and Turing complete? Crap, must have missed that thread

No Victor it does not pass the Turing test but who knows what the future holds. I have a love for AI so I’m just playing around with a few "informal" concepts.

Quote from: xwisdom at Jul 13, 2006, 05:06 AM

Quote from: vbrilon at Jul 13, 2006, 01:24 AM

Your parser is now fully sentient and Turing complete? Crap, must have missed that thread

No Victor it does not pass the Turing test but who knows what the future holds. I have a love for AI so I’m just playing around with a few "informal" concepts.

Hmmmm....Note to self: Don’t make jokes so obtuse

http://en.wikipedia.org/wiki/Turing_complete -- It’s named for the same guy as the Turing test, but means something totally different. I suppose I should insert a joke in here about Arnold Schwarznegger coming back from the future to stop Raymond’s parser from taking over the world, but I just can’t get anything going today.

Quote from: vbrilon at Jul 13, 2006, 12:36 PM

http://en.wikipedia.org/wiki/Turing_complete -- It’s named for the same guy as the Turing test, but means something totally different.

Thanks for the info

I suppose I should insert a joke in here about Arnold Schwarznegger coming back from the future to stop Raymond’s parser from taking over the world, but I just can’t get anything going today.

:)

Ok back to the parser...

I’m almost there with Beta 2. I have the eval() stuff removed and have tweaked things a little. Have to now resolve an issue with placeholders:

[[+PlaceholderB]]
[[SnippetA? &param=`[[+PlaceholderB]]` ]]
[[SnippetB]]

Where the value of PlaceholderB is set when SnippetB is executed

Looking at the above SnippetA is executed before SnippetB. This means that PlaceholderB will be processed before it’s value is set. The parser will need to detemine how it will handle the first PlaceholderB and what value it should pass to &param for the second PlaceholderB.

IMO the first placeholder should be processed after its value has been set while the second PlaceholderB should return an empty string to &param.

Any comments, suggestions or ideas?

Quote from: xwisdom at Jul 18, 2006, 08:12 AM

IMO the first placeholder should be processed after its value has been set while the second PlaceholderB should return an empty string to &param.

Raymond, I have to agree wit hthis functionality. As long as we create documentation that states if you are using a placeholder as a parameter in a snippet the placeholder value must be determined prior to calling the snippet.


Quick question for you about the new parser, in some of the snippets I have wrote I use the api function $modx->parseChunk($useChunk, $phArray, ’[+’, ’+]’)
Will this still function correctly with the new parser if someone sets their placeholder as [[+myPlaceHolder]]? Or will this function need updated? I haven’t had a chance to test it out yet, so if you want me to give it a try let me know.

Quote from: kylej at Jul 18, 2006, 08:22 AM

Quick question for you about the new parser, in some of the snippets I have wrote I use the api function $modx->parseChunk($useChunk, $phArray, ’[+’, ’+]’)
Will this still function correctly with the new parser if someone sets their placeholder as [[+myPlaceHolder]]? Or will this function need updated? I haven’t had a chance to test it out yet, so if you want me to give it a try let me know.

Once you have specified a prefix and a suffix tag then the parseChunk function will only replace those tags that exists.

I can make it so that the parser will auto convert [+ +] into [[+ ]] when the $modx->enableCompatMode property is set to true. When it’s set to false the parser will not parse the old tags.

What do you think?

Quote from: xwisdom at Jul 18, 2006, 08:41 AM

Once you have specified a prefix and a suffix tag then the parseChunk function will only replace those tags that exists.

I can make it so that the parser will auto convert [+ +] into [[+ ]] when the $modx->enableCompatMode property is set to true. When it’s set to false the parser will not parse the old tags.

What do you think?

If that is the solution here is what would need done to the snippets (correct me if I’m wrong)
calls to parseChunk need to be updated to use [[+ ]]
the snippet needs to set $modx->enableCompatMode = true (maybe through parameter setting)

That sounds like a pretty easy fix, that way we can ensure backwards compatibility for people who do not update there placeholders to the new format. Although we could just make it a required change for using the new version of a snippet?? For the future of modx this may be the way to go, more work to get updated to new version but less complicated in the future?

So I’m kind of torn between the two, backwards compatibility would be nice, but we need to weigh that against maintainability and the time that could be spent helping people solve issues with their placeholders.