MODx Recursive Parser - Beta 2a

I don’t (think I) want the extra overhead of debugging code in the parser. There is not global MODx debug mode right now.

I thought line 165 in index.php allowed to turn on error notice for the whole site :



Anyway, I am no coder, it was just an idea that came up... I am all for keeping the parser as fast as possible.
Complex snippets like Ditto can always have a debug parameter to allow debug mode...

Great work Raymond!

I especially like the perma-link feature and the url parameters.

Out of curiosity, what is our performance like compared to the old version? I haven’t looked at the actual code yet but if it would save a decent amount of processing time it might be worth having a backwards compatibility mode that is turned on by default but could be turned off to speed things up.

Debug mode to me implies a lot of extra code that echos back what is going on. Stop on notice is cool too.

@Dimmy,

Quote from: Dimmy at Jun 21, 2006, 02:23 AM

so what if I made a snippet called The mary had a little lamb nursery rhyme... ? or are spaces not alowd in a snippet name? wil they be replaced by a - ?

Currently you can have spaces inside snippet names. If you have a snippet called "The mary had a little lamb nursery rhyme... " then the parser would execute it. The problem starts when it does not find it. What should the parser do? Should it remove the [[The mary had a little lamb nursery rhyme...]] and treat it like a missing snippet or should it ignore it?

Things will get a bit more complex if you have something like this inside your document:

[[Lesson 1
Some text here some text here...
Some text here some text here...
Some text here some text here...
Some text here some text here...
End of Lesson 1 ]]

I’m thinking maybe we do need to apply rules to resource names. Maybe we should only allow characters such as a-zA-Z, 0-9,-,_,.

What do you think?


@David,

Quote from: davidm at Jun 21, 2006, 05:28 AM

One way to settle this would be to have something displayed if debug mode is "on" (some snippet have a debug parameter, like Ditto).

Yes there are debugging options inside the parser but they are turned off by default. So no perfomance lost if it’s not enabled.

Let’s say I am improperly using a snippet (say, forget to close a backtick or whatever), if the parser just ignores it as an invalid call, it would help to know that something if wrong, rather than have it output an empty string... wouldn’t it ?

Yes I would agree with you but if the parser assumes that it’s a valid snippet but it does not exist then it should return an empty string.

@Adam,

Quote from: aNoble at Jun 21, 2006, 09:19 AM

Out of curiosity, what is our performance like compared to the old version?

On my old PC (800Mhz Duron) I got the following results:

MODx Default Installation Home Page
--------------------------------------
Old Parser: 0.30 to 0.33 seconds
New Parser: 0.30 to 0.34 seconds (with automatic conversion)

In my estimation both operates at pretty much the same speed for simple pages. It’s still in the early stage and needs a lot more testing and performance tuning.

I haven’t looked at the actual code yet but if it would save a decent amount of processing time it might be worth having a backwards compatibility mode that is turned on by default but could be turned off to speed things up.

Yes, we can make it optional.

@Ryan,

Quote from: rthrash at Jun 21, 2006, 09:33 AM

Debug mode to me implies a lot of extra code that echos back what is going on. Stop on notice is cool too.

I agree but we still need a little code to tell us what’s going on inside the system when something goes wrong

Quote from: xwisdom at Jun 21, 2006, 09:51 AM

@David,

Quote from: davidm at Jun 21, 2006, 05:28 AM

One way to settle this would be to have something displayed if debug mode is "on" (some snippet have a debug parameter, like Ditto).

Yes there are debugging options inside the parser but they are turned off by default. So no perfomance lost if it’s not enabled.

Let’s say I am improperly using a snippet (say, forget to close a backtick or whatever), if the parser just ignores it as an invalid call, it would help to know that something if wrong, rather than have it output an empty string... wouldn’t it ?

Yes I would agree with you but if the parser assumes that it’s a valid snippet but it does not exist then it should return an empty string.

Thanks Raymond for those answers

I must say I am in awe with the possibilities opened by the new parser... right now I am trying to wrap my head around them !
It’s neurone warm up time !!!!

I think MODx users won’t believe their eyes, can’t wait to see that !

I did not have a chance to test the new parser out yet (have you guys ?)... but now that I have carefully read the attached doc, I’ll start doing some testing...

One of the things which is the most exciting is conditionnals... and about that, there is only one of the 9 tags I am uncertain about :



What should be passed into the &pattern parameter ?
Thanks !

Quote from: davidm at Jun 25, 2006, 03:01 PM

IF-MATCH &pattern=`//` &value=`` &then=`` &else=``

What should be passed into the &pattern parameter ?
Thanks !

Hi David,

Sorry about that I was very tired when I wrote the doc

The anywhere you see the &pattern and &match parameters they all use php regex patterns.

example:

[[:IF-MATCH &pattern=`/world/i` &value=`hello world` &then=`A match was found` &else=`No match found` ]]

Here’s another example where we could use this tag to test for a valid phone number that was submitted using a web form:

[[:IF-MATCH
&pattern=`/(\d{3})[\-\.]?(\d{4})/`
&value=`[[:REQUEST &name=`phone`]]`
&else=`Please enter a valid phone number`
]]

Quote from: xwisdom at Jun 26, 2006, 01:22 AM

Hi David,
Sorry about that I was very tired when I wrote the doc
The anywhere you see the &pattern and &match parameters they all use php regex patterns.

Thanks Raymond ! I guess I didn’t understand because I am not familiar with regex patterns... Now I have to start learning this !

Anyway, the doc is a great helper discovering the new parser, it was the only interrogation I had while reading it

Would it be an option to have an extra global setting for debug mode that way you could set the whole site to production/debug and have an option for snipet coders to look at that value and that way switch on/off the debug mode.

@raymond

I think when we have snippet calls that doe not work that the whole snippet call must be blank if not in debug mode, why would you use a snippet thats not existing? and why would you then have an option in the call made by another snippet/tv/chunk/etc that is existing ? that call is only usefull when the nonexisting snippet does exist (thats why its there in the first place).

so if we would have a global debug parameter (on/of) we could send info back that the snippet that we typed in is non existing, while on debug mode but when debugmode is set off then it should not whine and just return nothing.

Thats how I think it should work.

Dimmy