Intelligent Parallel Parsing (P^2)

And actually, a more appropriate name for the technique is probably "Pendulum Index Parser (PIP)", as it’s not really doing a parallel job but drilling down and bouncing back and forth as it goes through and finds start and end points, like a Pendulum... but resuming when possible from the outermost "index points".

Or the TSFOSB Parser (two steps forward, one step back).

Pretty crafty stuff Raymond!

But I think we’ll just call it our "parser" in the vein of keeping it simple and sweet for folks that would never get it anyway!

Thanks Ryan,

There’s some other things tweaks thats needed but this is just to surface for now. You can try adjusting the cache settings to see what the output looks like:



PS. Parallel Parsing is not really the name for it. I just came up with that term to descript how we can handle content caching and content display parsing.
So I guess it’s still just parser at best.

Hello Everyone,

In an effort to bring get the best out of MODx I’ve just spent serveral hours trying to fix a bug detected when parsing multiple/nested/cached/non-cacheable tags! It was a nightmare! The good new however is that it’s more intelligent than before. I call it P²:

Consider the following tag:

[[A? &p1=`[[B? &p1=`[[C]]` &p2=`[[D]]`]]` &p2=`[[B? &p1=`[[E]]` &p2=`[[F]]`]]`]]

If [[E]] was maded non-cacheable the parser would be intelligent enough to detect this and force tags [[A]] and [[ B]] to be non-cacheable as well. This means that the values of [[E]] will always be passed to [[ B]] as shown below:

[[A? &p1=`3` &p2=`[[B? &p1=`[[E]]` &p2=`8`]]`]]

All the other tags will be parsed and passed in as static values with the exception of [[E]].

As a result of this intelligence the parser is now able to support parallel parsing on multiple levels of cached vs non-cacheable tags:

Consider where [[E]] is set to non-cacheable:

[[A? &p1=`[[B? &p1=`[[C]]` &p2=`[[D]]`]]` &p2=`[[B? &p1=`[[E]]` &p2=`[[F]]`]]`]]
[[E]] [[ B]] [[E]]
[[A? &p1=`[[B? &p1=`[[C]]` &p2=`[[D]]`]]` &p2=`[[B? &p1=`[[E]]` &p2=`[[F]]`]]`]]

This will result in a cached output of:

[[A? &p1=`3` &p2=`[[B? &p1=`[[E]]` &p2=`8`]]`]]
[[E]] 15 [[E]]
[[A? &p1=`22` &p2=`[[B? &p1=`[[E]]` &p2=`27`]]`]]

Note here that the [[E]] tag generates an output of embedded tags [[G]] [[H]] [[I]]. If we were to only set [[H]] as a non-cacheable tag the parser would render the follow:

10
11 12 [[H]] 14 15 16 17 [[H]] 19
29

If we were to set both [[A]] and [[H]] as a non-cacheable tag the parser would render the follow:

[[A? &p1=`3` &p2=`[[B? &p1=`4 5 [[H]] 7` &p2=`8`]]`]]
11 12 [[H]] 14 15 16 17 [[H]] 19
[[A? &p1=`22` &p2=`[[B? &p1=`23 24 [[H]] 26` &p2=`27`]]`]]

The tags used above represents complex layouts that are now possible with the new parser engine. Most day to day designs will not require such complex layouts but it only goes to reveal the true power of the MODx system

What do you think?

If someone writes widgets that convoluted, they should be shot!

But it’s really cool that it’ll handle it. Nice work!

Yeah I agree. Shoot them

Nice work Raymond, that’s pretty impressive stuff

Maybe I’m missing something here, but can someone explain a scenario where an uncached snippet embedded in the properties of another would provide any functionality at all? If the snippet depending on an uncached snippet is cached, then by necessity the cached value of the uncached snippet would already be embedded in the logic of the cached snippet.

Totally confused as to the point of this...the only time we should ever parse a nested tag, is when the tag it is nested is uncached, period. What am I missing...???

Jason,

Lets say you have WidgetA and WidgetB. WidgetA was designed to change the template of the page and is set to being cacheable by default;

example:

[[WidgetA?tpl=`Daylight`]]

A user now wants to do this dynamically by passing a value from WidgetB to WigdetA. He creates WidgetB sets it to non-cacheable and update his page:

example:

[[WidgetA?tpl=`[[WidgetB]]`]]

The system will not force WidgetA to not be cached since it has a dynamic parameter being passed to it.

Another real world example would be Susan’s multi-language setup.

Let’s say she wants to change the language used inside her panelbar widget but this widget is defaults to being cacheable. She does not have to change the widget to being non-cacheable. All that see needs to do is set the pass the non-cacheable TV to the widget and the system will read it at all times.

In this case PanelBar will be non-cachable due to MyLang

[[PanelBar?lang=`[[*MyLang]]` ]]

In this case PanelBar will default to being cachable

[[PanelBar?lang=`en` ]]

My point is, anything created as a cacheable snippet will process nested tags ONLY when it is not cached -- in both of these cases, neither of the snippets would ever be cached (why would PanelBar be cacheable by default if it’s always going to be called with a language attribute, which really should be internal to the request anyway, and not necessary in the tag), so I still don’t see this as a valid scenario. I don’t want a nested tag’s cacheable attribute to affect a tag a specifically indicated would be cached, EVER! I’m still missing the use-case here, cause the instance of the Widget/Element (I do like Element much better than Widget BTW) tag in a page would be either be cacheable or non-cacheable. Forcing the evaluation of nested tags inside a another tag that already defines it’s cacheability is overhead I’d rather not see when processing cached documents/resources.

In the above PanelBar is not always non-cacheable. It’s cacheable by default. The system no longer supports the [!!] tags. Means that you can control the caching from withing the source or from an option when editing the Widget. If you would like to do it the old way then that’s ok.

Now what happens when a user passed a dynamic value to your widget and then realize that it’s not processing the value at all? It just keeps on diplaying the old value. Should we then say to them set it to non-cacheable for all pages? Or should we tell them to type in [[!WidgetName]] just like to good old days? I think we are trying to get away from that experience, aren’t we?

Consider this:

[[Panel?content=`[[Clock]]`]]

Now the panel widget is cacheable while the clock widget is not. The clock widget is programmed to always return the time. With you solution you would have to set your panel widget to non-cacheable in order to view the clock right? But with the new system you don’t! The question is why would you want to pass a non-cacheable snippet to a cacheable one if you don’t expect the output to be changed?

On the issue of Element vs Widget, consider the following combinations:

Button widget
Panel widget
DropDownMenu widget
DataGrid widget
DataList widget
Tab widget
Clock widget
Textbox widget

as oppose to:

Button element
Panel element
DropDownMenu element
DataGrid element
DataList element
Tab element
Clock element
Textbox element

I think that just because you can doesn’t force you to do so... I CAN drink Liquid Plumber, but I CHOOSE not to do so as it’s a non-sensical use-case for me.