MODx Recursive Parser - Beta 2a

There are two options as I see it:

A. Create default snippets for the commonly used conditionals needed and deliver them in the default content of a modx install.
(Parser needs to be at least recursive for this to actually work.)

B. Come up with a core addon for MODx that defines a simpler method (using modx style tags) of doing the templating.


Both methods would set a standard for MODx developers and/or even template designers to deliver their products without introducing new ways of iffing a then

@Jason : thanks for taking the time to explain and give some samples, it sure is a lot clearer

I think the different takes on this matter are purely a question of point of view, and also the fact that MODx is both a CMS and CMF. It has a set of built-in feature which works "out of the box" along with expandability through its API and DB API.

I can easily understand how from a coder’s point of view A) would seem purer and better but as a designer I sure feel better using B) I have enjoyed the conditonnal tag method back when I used Texpattern and it sure made life easier as far as templating is concerned. It’s the CMS point of view, being no coder I can’t just write a snippet when I use a conditionnal in a given context, if the system provides tags to do just that, that’s great. Now the CMF approach would certainly lean more on having people rely on a solid API so that they can easily build those snippets quick and nice.

This being said, I am far from being qualified enough to say which option is better. The only thing I can say is, I do agree with bS whatever is chosen is based on a consistent method (not a different method for each snippet)...

Quote from: PaulGregory at Oct 09, 2006, 05:04 PM

where I don’t actually want to output a div if that snippet isn’t going to return anything, but also I don’t want to specify the div in the snippet template because I may wish to use different variants on different layouts.

You’ve lost me; I wasn’t showing anything related to conditionals in this example. I was simply showing an example of the use of formatting modifiers vs. what things like PHx and other templating solutions are introducing. I think introducing all these different methods of doing these kinds of things is not in our best interest as a community or product, and I am trying to simply get us working more collaboratively as a development team on consistent, simple, and robust resolutions; not impulsive solutions that stem from a "I need this now so I’m going to hack it into the code cause it works" approach.

Quote from: PaulGregory at Oct 09, 2006, 05:04 PM

And I fail to see how shunting stuff off to a snippet to do an IfElse is any less a chaotic mix of logic and presentation from the point of view of the user. Sure, it protects the purity of the parser, but it looks like a workaround.

Think of it like this; everytime the parser has to handle a different set of tags or tokens, it increases the processing time of every single component being parsed. That, IMO, is even more important than the fact that conditionals would best be served if delegated to a single top-level representation via a tag; not via hierarchical markup-like tags that must have a beginning and an end. Then user interfaces can be made to properly edit embedded templates in a very user-friendly manner when dealing with conditionals. This is a problem I’ve dealt with since JSP and I just don’t see traditional conditional tags like what is being introduced in Raymond’s version of the parser, or is used in existing templating solutions like Smarty, as the answer. I think that approach to the problem has hit a dead-end.

I’ll also say right now, the "purity" and maintainability of the parser and all of the core code is my number one concern and certainly what has motivated me to spend my free time for the past year to rewrite this application in what I feel is a proper architecture. Period. I guarantee you we would quickly lose traction and viability as a long-term project if we just continue to slap features into the mess of spaghetti we have right now in an ad hoc fashion, despite the ease with which it can be done currently.

Quote from: PaulGregory at Oct 09, 2006, 05:04 PM

You’ve gone off on a tangent there. It all sounds great and positive, but this masks the fact that you’re basically saying "No". You’ve redefined the problem, and then just said "With this solved..", and argued the case *for* each snippet having its own different templating system (whatever is most efficient for that component).

Importing and exporting related components is *not* the only real problem. The bigger issue is the wildly different templating formats that users must learn. Many will assume the first one they come across, be it Ditto or Wayfinder, will be the "official" way to do it. Re-use of skills - that’s useful.

So, what is the best future-proof way to achieve what bS talks about?

A tangent?! I’m not saying no here at all; I’m offering you my vision of how to get from here to there and what I see as the primary bottleneck in that vision. And I stand firm IMO that our team members have never learned the proper way to template using MODx simply because there is no easy way to move sets of related components together.

bS and I have been in touch today via IM discussing this in-depth. Feel free to take some of this offline with us, or join us in the IRC channel if you don’t quite understand what I’m trying to say here. I know I sound dense at times; it’s just the way it comes out naturally, and without a lot of editing and dialog, sometimes I don’t understand what I’m saying at first. But I promise I’m trying to do what’s best to solve this issue of disparate templating approaches, and I’m a bit shaken by your responses here...

Jason, I don’t think anyone is questionning your comittment to trying to do what’s best, especially since lots of us are just in awe reading about the concept you have in store for 1.0 (I know I am). I know I try to follow up on your post so that I don’t get lost along the way, it takes time to grasp xPDO, object oriented sample code you provided, things you posted about 1.0. It seems quite groundbreaking and innovative, so much so that despite the time and efforts you have put into that, the problem is just for some of us understanding the advanced concepts you’re using to build the next MODx, and why such and such options are better than others.

I think templating will be a key issue for designers, since it’s the main aspect of MODx we have to master to get our part of the job done. I admit I have been excited about the new parser and new possibilities which could potentially arise from it. Conditionnal testing is a huge addition to what is currently available through MODx tags. Now about tags : I have read a bit about the performance issues around having tags instead of raw php directly into templates, and I do understand that the later is faster than the first but at the same time I think as designers it makes our life easier having tags to work with (That’s why I chose Texptattern over WordPress back when I looked for a blog app). It’s also more familiar and readable. But sure, performance should be a big factor in choosing the future templating system. Where does the balance stand ? Which choice is better ? Well, I don’t know and I trust you and the dev team to make the architectural choices.

If I understand correctly what you’re saying, MODx will rely more on the API, and less on built-in features making it more flexible and closer to a framework than a traditionnal CMS. That’s a great thing, but we have to get a grasp on what this means. Your explanations sure help but also raise even more questions.

I am fairly sure that 0.9.7 (or whatever codename is picked), with the backported code from 1.0, will help us make the transition.

Quote from: davidm at Oct 09, 2006, 06:10 PM

If I understand correctly what you’re saying, MODx will rely more on the API, and less on built-in features making it more flexible and closer to a framework than a traditionnal CMS.

In way you could say that, though in an MODx analogy, the API’s represent a permalink or alias to represent some behavior, and the actual way that behavior is accomplished is delegated to whatever "page" you configure as the implementation of that behavior. In other words, I can override or replace specific behaviors in the parser by simply providing my own parser class file that overrides just the methods you want to change. No core code ever has to be changed, and you can implement those behaviors in just about anyway imaginable.

My responses that are not primarily about the topic (MODx Recursive Parser - Beta 2a) are being taken to PM. (Although I should point out that I knew OpenGeek wasn’t showing anything related to conditionals in the code I adapted, my whole point was that adding conditionals to that code example would be cumbersome.)

I’d just like to focus this thread on one crucial point:

[...] I just don’t see traditional conditional tags like what is being introduced in Raymond’s version of the parser [...] as the answer. I think that approach to the problem has hit a dead-end.

Woah. Are you saying that Raymond’s parser isn’t the way forward, or that you can’t move forward from Raymond’s parser? In other words, do you see the official ultra-pure 1.0 parser including these conditional tags, or should that move to a plugin? Looking back, I see you said:
Quote from: OpenGeek at Oct 09, 2006, 10:11 AM

This [belief that it encourages a chaotic mix of presentation and logic] is the same feeling I have about conditional tags, and beg that they be removed from this parser and implemented as simple add-ons as they should be.

The feature of looking up data from other content, that I could understand as being an add-on, as it seemed a stretch for a parser. But the basic conditional tags... If you take them out, the parser is significantly less exciting.

Now, it is my understanding that there is a version of 0.9.7 that broadly works, but which is somewhere between 1.0 and the early 0.9.5s.

Although it is up to Raymond what goes in his parser, it seems to be up to Jason what goes into 0.9.7/1.0.

If the conditional parts of Raymond’s parser will be vetoed for 0.9.7/1.0, then it will be very confusing to release it in full as 0.9.6 unless the conditional tag add-on is included in 0.9.7. (One should never add a feature that won’t either stay or be replaced by a comparable feature in the next release).

So, should the conditional stuff stay in this parser?

This decision appears to hinge on whether you see MODx’s future as a pure, easily-maintainable core or a flexible multi-functional core. If there is disagreement here (as there seems to be), the decision’s importance only increases.

I have also silently thought my self that what’s the point of introducing a new parser and syntax features in 0.9.6 and then completely change it in 1.0.. unless there is a big time difference between those releases. I bet that if the conditionals are introduced in 0.9.6, people will very much like them to be in 1.0 too..

But I have also talked about this few times with Jason and he said that the syntax of this recursive parser can be supported in 1.0 too via doing it as a extension to 1.0 parser.. but would it be more like backwards compatibilty addon and not official support, i dont know..

Some discussion about this in this thread: #1, #2, #3.

All in all, I trust in the head honchos to do what’s best for the project.

There won’t be anything introduced in any version that won’t be fully supported going forward, and there’s a lot of discussion going on behind the scenes to get everyone on a unified vision for future releases. This (unified vision) is exactly what Jason was bringing up... haphazard additions to the core to fulfill a short term need no matter how good they seem on the surface can have major impacts on the core that has been in development for a LONG time.

In all fairness to the points raised here, I agree that it’s very difficult to grasp a lot of what Jason says without seeing and playing with the code itself. When you’ve been involved in creating something for ~1 year, it’s easy to grasp implications and see potential warning flags. When you hear about it in sporadic, highly technical posts containing a lot of concepts from the enterprise-world, it’s quite confusing even for me and I HAVE touched/seen the code (or as I like to call it "whoosh" as the explanation flies over my head).

Not having first hand experience can cause someone to think Jason’s advocating less flexibility or suffering from "not invented here" syndrome, but I know that’s not the case. In fact, he’d love for folks to actively engage in a dialog and contribute to the development of the next generation core. More soon I’m sure.

I think that dialog will happen once "the wolf is out of the wood" so to speak (and I am sure it’s going to kick a*s !). Given the current team and community dynamics, I have no doubt once things start to unveil with 0.9.7 there will be lots of questions and discussions and experimenting (and enthusiasm ).

Many thanks for the all feedbacks on the parser. Didn’t know we had so much to share

Quote from: OpenGeek at Oct 09, 2006, 05:43 PM

Think of it like this; everytime the parser has to handle a different set of tags or tokens, it increases the processing time of every single component being parsed.

Really? Have you looked at the code inside the parser and how the conditional tags are invoked? How would removing them from the parser increase the speed of the parser? Or how would using snippets give better performance?

This is not the first time that we have discussed things like this and we end up with two different approaches. I guess the integrated conditional tags are not viewed as proper architecture and will therefore not make it into future releases of MODx.

I guess this is where it boils down to what we feel is better for the system.