Welcome Guest, Not a member yet? Register   Sign In
Use of Closures in Views
#21

(09-25-2015, 08:26 AM)mwhitney Wrote: Eventually, I hope to get around to replying to everything directed towards me since my last post. However, I wanted to point out that quirk #3 is of course isolated to 5.3, and does not exist in 5.4+. I also happen to know that @kilishan has used $this in an anonymous function at some point, because it had to be rewritten to support PHP 5.3 Smile

Oh, wow, I did, didn't I!? Guess I didn't realize because I didn't realize it was something you weren't supposed to be able to do. And now that I know - it's too late because PHP already supports it.
Reply
#22

(09-25-2015, 11:00 AM)spjonez Wrote: [...]

(09-25-2015, 10:03 AM)mwhitney Wrote: 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.

[...]


(09-24-2015, 07:29 AM)mwhitney Wrote: 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.

I omitted most of the conversation because I think it really comes down to, more or less, what you've said in these two responses. For you, the application builds a client in JavaScript which builds the user interface, displays information to the user, communicates with the server, etc. With all of this discussion of views, you don't really seem to use the View layer in CodeIgniter for handling most requests.

For me, the use of a JavaScript client has to be presumed invalid from the start. It can be added as an option, after the HTML/CSS client is complete. In some ways, your approach can still be useful and beneficial with this assumption, but it can be difficult to see how you could implement a thin View layer on the same codebase to perform at least the minimum functionality of your JavaScript client on the server.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB