Use of Closures in Views

At this point, you're looking at a whole series of trade-offs between performance and complexity in several different portions of the application. However, the only thing that really has anything to do with the view is that you're advocating formatting data while performing other processing, but still before passing it to the view. In my opinion, most of the processing you're talking about should be performed in the model (or the SQL, because sometimes it is faster there), but the only way the model can format the data for the view is if you provide the model with a lot of information about the way in which the data will ultimately be presented.

Yes I perform queries in models, typically as a single query then I loop and format the results in PHP. If for whatever reason you have a datetime and want two distinct formats you can always add keys as you loop.

Which is it, the views are presentation or compilation should be involved

Presentation is a representation of the data. I should be able to use the same data array and present it as HTML, CSV, or any other format without each compile requiring special functions.

Even if you create a single-page application and require your user to have JavaScript enabled for your site to even function, you have to send HTML in response to the first request.

You can send an uncompiled view and the data as JSON to the client, then only send the data on subsequent requests and cache the view in the DOM or localstorage. This abstraction is required for things like two way data binding. If you don't you'll be sending HTML blobs and delegating events on parent containers which is not performant or maintainable long term.

Further, it's unclear here whether you are encoding to JSON directly from a controller or you're actually using a view for this purpose.

I'm returning JSON from the server. Views are included as a key.

Is it just the presence of PHP in a view that offends you? After all, it sure sounds like you're perfectly OK with off-loading a lot of logic to the client.

PHP in views drives me crazy. Yes it's fast, yes it's easy, but it's a poor way to manage a code base. Why create a dependency when you don't need to? Why should my server have to hit the disk every time it wants to generate the same view over and over?

The amount of work and planning has nothing to do with this particular choice. It takes a little more work to write my own JavaScript framework or my own templating language, if I feel I need them, but I would usually only choose to use one (or both) because it made it easier, in the long term, to do what I need my site to do. In other words, I would usually choose to do something like that because it reduced the amount of work I needed to do. The amount of planning required should not change at all, but it is easier, in the short term, to just start writing code without planning much of anything, and none of us are likely to make informed architectural decisions about our sites that way.

That depends on your project needs. Long term flexibility is something we should all think about when we build applications at scale.

My main point, though, was that you're not removing logic from your views, you're simply moving it to another portion of the View layer. If PHP parses the template, it's possible that the parser itself is relatively well isolated from the view layer, but the use of the parser to convert the template is still a use of logic within the view layer. If JavaScript parses the template, somewhere along the line the parser itself is in your view.

I tend to think of MVC layers as independent systems. Controller takes a request and validates it. If data is required from your database it may request data from a model. The result is handed to a view which compiles it. By using a templating language your view is a standalone system that's simply injecting strings into a fragment. Want to use Mustache? Handlebars? doT? What if you want to template client side? The transition is easy.

No, I usually don't use an ORM, but an ORM shouldn't have any impact on whether you have to loop through your results in a view, because the ORM is accessed by the Model.

The reason I asked is with an ORM you often receive data back as a nested array/object. If your data is already well formed you can call functions from views (formatting etc) and skip the PHP loops which the ORM is doing for you. Under those circumstances users may forgo pre-processing to avoid a perceived hit to performance.

You jumped right on that idea of separation of the logic from the View, but you don't seem to care about the separation of any of the other layers, and I see no acknowledgement of the amount of logic required in the View layer for the alternatives you propose.

View parsing can be automated. Ember does it, Angular does it, Cinder (my project in the Addins forum) does it.

What I'm advocating for is treating your application like a series of micro services each with a distinct job and minimal awareness of the layers surrounding it. And to avoid vendor lock in where you can. One of the biggest mistakes I made starting out with CI was using PHP in views instead of the template parser class.