PW 3.0.49 core updates

[ryan]

This week we take a look at a new template file output strategy available in ProcessWire 3.0.49+. (Not to be confused with a “template system” like Twig or the like, as our template system is PHP). This strategy is an experimental but super-simple new alternative to direct output and delayed output, and in some ways a combination of both. Yet it’s likely to be more accessible for front-end developers and newcomers to ProcessWire, without sacrifices. Have a read and let us know what you think.

https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/

[Robin S]

This is freaking awesome - I love it!

I've always disliked working with HTML markup inside PHP variables - the sacrificed readability of the HTML that comes with multiple variable concatenations, the single quotes/double quotes/escaped quotes hassle. I try to avoid it as much as possible using output buffering but this new feature suits me down to the ground and will definitely be my preferred way of managing markup in templates going forward.

Simple and brilliant, like the rest of PW. Thanks!

[AndZyk]

So many ways now to structure templates. 

Sounds definitely interesting, for the reasons @Robin S listed.

[LostKobrakai]

To be honest I'm not sure this will make things considerably easier to grasp for (new) people. I can already see people trying to use it as replacement for a templating language. I really don't think it's worth it just to not have a $main/$sidebar variable, especially for new people. I'd imagine it's more confusing than helping.

I'd much rather would like to see a guide dedicated to examples of direct output -> delayed output -> separation business logic / view logic -> templating engine (twig/blade), what the benefits are and how to switch between them (e.g. same output in different strategies). Especially the third one is a kinda pet peeve of mine, because I went into the rabbit hole myself, where markup was so deeply coupled with processwire api stuff, that it was a nightmare to change anything. For me this seems to be more in line with your motto of teaching people how to fish.

[szabesz]

https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/#Comment12849

By Ryan: "What's described in this post is not a template engine, and not even related to a template engine. Actually it should work quite nicely alongside a template engine if you are using one. What markup regions do is essentially the same thing that the existing PW region() function does, but with some added flexibility and simplicity."

If it can be used together with a template engine, then it is the way to go I think. While teaching to fish instead of simply feeding is good a concept, when there are so many different ways to fish, you have to start teaching by using one method only so that all the newcomers can learn the same thing at least at the beginning. This new method/strategy reminds me of Magento, but it is a lot simpler to implement. I do support it. Let's teach people (ourselves to begin with) how to use it with and without a template engine  

Edited January 16, 2017 by szabesz
typo

[LostKobrakai]

7 minutes ago, szabesz said:

…, but it is a lot simpler to implement.

And as likely to misuse. I don't want to say that it's not easier in some ways, but I fear that people – especially the target group, new to processwire, never heard of region api –  misunderstand what it's meant for.

[Lenz]

very interesting discussion here.

@LostKobrakai: If you don't mind, could you elaborate a bit more in detail why this new template strategy could be misunderstood or confused with a template engine?

I really don't get the point, but would like to. To my - admittedly rudimentary - knowledge a template engine like twig adds only a little bit syntactic sugar like
{{ var }}
or something like
{% block content %}
    Content of the page...
{% endblock %}

But what has this to do with the template strategy Ryan introduced here?

And i also fail to understand in which regard the new template strategy could potentially lead to a tight coupling of markup with api stuff?
I mean isn't the separation of business logic and view completely independent of using an engine like twig or not? Or in other words: Couldn't you mix up markup and business logic as easily with twig as wihtout it?
Or again in other words couldn't you use the MVC pattern as easily with Ryans new template strategy as without it? (-> would like to know more about how to use MVC within PW templating btw...)

just curious...

[Robin S]

7 hours ago, szabesz said:

By Ryan: "What's described in this post is not a template engine, and not even related to a template engine.

I think this new approach is similar to template engines in one respect: the idea of extending a named block. This feature is present in template languages like Smarty and Twig and I for one find that feature very useful. I don't see any other similarities to template engines though.

7 hours ago, LostKobrakai said:

And as likely to misuse.

What would be your idea of misuse of this new strategy? If you mean it allows (encourages?) developers to not follow the MVC pattern then I don't see this as a big issue. There is no cardinal rule: "Thou shalt use MVC in all projects" - it depends very much on the type of developer you are and the type of project you are working on.

When Ryan says...

On 14/01/2017 at 10:57 AM, ryan said:

Yet it’s likely to be more accessible for front-end developers and newcomers to ProcessWire, without sacrifices.

...I take this to mean people who are new to PHP development in general. People who have a design background, or those used to a drag-and-drop interface, or who have previously worked only with static HTML. If someone has a lot of PHP experience I doubt they would find anything about PW difficult to understand - more like a breath of fresh air.

And people who are new to PHP development are not going to be:

• building large, complex web projects
• working on long-lived projects that will be handed over to future developers
• collaborating on a project with other developers in a team

For any of these I totally see the value of MVC. But if you are a newbie working on <10 page brochure websites you do not need MVC.

[szabesz]

LostKobrakai did not mention MVC at all, probably he did not even refer to it , as far as I can see. Speaking of MVC, I'm not convinced that "strict MVC" is that much useful either, and I'm not alone eg.: http://paul-m-jones.com/archives/6288

But either way, I do agree with  @Robin S that lots of brochure websites do not need MCV or the alike, and even webshops can be successful without them especially if one does not have to refactor too much in it the future for some reason. When a system is based on solid system design (meaning the site does what the client needs in the first place) then there is less to worry about regaring possible refactoring. But it is getting off-topic here...  

 

Edited January 16, 2017 by szabesz
typo

[Robin S]

2 minutes ago, szabesz said:

LostKobrakai did not mention MVC at all, probably he did not even referred to it , as far as I can see.

He talks about the separation of concerns...

9 hours ago, LostKobrakai said:

I'd much rather would like to see a guide dedicated to examples of direct output -> delayed output -> separation business logic / view logic -> templating engine (twig/blade), what the benefits are and how to switch between them (e.g. same output in different strategies). Especially the third one is a kinda pet peeve of mine, because I went into the rabbit hole myself, where markup was so deeply coupled with processwire api stuff, that it was a nightmare to change anything.

...and MVC is a popular pattern that enforces that. But they're not exactly the same thing, for sure.

[LostKobrakai]

@Robin S It wasn't my intend to talk that much about separation of concerns at all, but about the fact, that people new to ProcessWire need a system which is first and foremost clear to grasp. This new region syntax is in my opinion the opposite. It might work for the tutorial type of situations, but I'm not sure it'll hold true for much beyond that. My biggest issue with it is that it's keeping it's state without any clear indication of what's happening. Someone who didn't read the docs on this feature or maybe just skimmed it lazily won't be able to tell why things happen as they happen. And that's probably the average guy or gal out there trying out ProcessWire for the first time; clueless of any of the magic id matching happening in the markup.

The older function-based implementation of the regions api is way more explicit in telling even the clueless reader of the code that stuff is being placed in some kind of regions, which are later printed in the wrapping markup. 

My addition of "separation of concerns" as part of an educational piece on templating was just for it's own sake: education. I see lot's of code examples around the forums, which are just a mess of business logic mixed with view logic mixed with html markup. Such code is a nightmare if the client comes around and asks you to change some things here and there. Even better if things should later be used in multiple different places. It would be a shame to leave those issues out when discussing the differences between templating strategies in processwire.