TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Once you go VIewModel do you ever go back?
  • I have been using Zombor's wonderful KOStache ViewModel module for quite a while now and I simply love the separation of concerns.

    Sometimes I'll find myself perusing through github looking at some different PHP applications and it seems like there aren't a whole lot that use the ViewModel pattern. The thought of going back to having a fat controller and loading a php template the controller grosses me out when I think about it.

    So how about you, have you ever used the ViewModel pattern? If so are you still using it?

  • You don't go back. You laugh at all the idiots doing it wrong :)

  • I agree. ViewModel is the piece of cake I miss from Kohana Core at this moment. I hope to see ViewModel in next version core !!

  • @evanpurkhiser

    Sometimes I'll find myself perusing through github looking at some different PHP applications and it seems like there aren't a whole lot that use the ViewModel pattern. The thought of going back to having a fat controller and loading a php template the controller grosses me out when I think about it.

    The thought of using another template inside a perfectly fine template language grosses me out.

    But if it works for you it's not like I care. :) It's not a better way, it's just a different way. As they say "Mind your own beeswax." You can write perfectly good code with any pattern, similarly you can write perfectly dumb code with any pattern. Some patterns may require less understanding on what you're writing then others, that doesn't make them better, and it doesn't make them worse (well, sometimes it does but whatever). Judging by your argument you were simply writing bad code before... the whole "fat controller" deal is not suppose to happen.

    I would advice against becoming reliant on languages and patterns holding your hand; have some faith in your ability to write code.

  • @Akki You don't have to use Mustache / KOStache in order to implement the ViewModel pattern. It's perfectly fine to use pure PHP in your views, just need to be careful not to inject logic into it, and that's where Mustache shines.

  • Will ViewModel be supported in 3.3 core?

  • @feketegy cool explanation. Thanks.

  • just for information, FuelPHP has viewmodel in the core http://docs.fuelphp.com/general/viewmodels.html

  • @feketegy

    Let's say I have one Controller and one Model. The details for the Controller and Model aren't important but basically let's say you have two Views both of which get $categories from the model and use the same controller. The categories are represented as an array. Each category can have categories and each of those can have categories of it's own... and so on to infinity.

    The first view displays only the top level categories, the second view displays all and has some special rules for them, such if a category has more then X sub categories it displays them in a different way and things like that.

    That's all display logic. It's just one has more complex display logic then the other. You can do it with just the one view file, with out invoking additional classes or calling views. But that's probably not going to be the case if you blindly go and use the ViewModel pattern though; guaranteed if you use Mustache. Which is nothing against the pattern itself, it's just a case where it's not necessarily the best place for it.

    Of course not everyone needs encapsulation within views since most of the time you don't have alternative views. But like I said it's a matter of understanding your goals and writing the best code for the job; not just throwing patterns at problems and telling yourself "the code is right, because I used trendy pattern X".

  • @Akki I found that for most cases ViewModel is a good pattern to use, and not just because I want to use a trendy pattern. Using ViewModels is much much easier to unit test that part of your application, because ideally you don't have any logic in your Views.

    So PHPUnit for Controllers, Models, ViewModels And Behat for functional testing.

  • And why are you unit testing Views and not just the business logic? :) Not sure I see the point in it, can you elaborate.

  • I'm unit testing ViewModels, not Views. ViewModel contains the logic for the View.

    I use functional testing for the whole application using Behat / Mink.

  • Will ViewModel be supported in 3.3 core?

    No, it didn't make it in. Maybe 3.4.

  • Witch module might be included in 3.4: ViewModel or KOStache (both by Zombor) ?

    ViewModel wasn't updated for a year - it's dropped in favour of KOStaches ?

  • Neither. We don't know yet, but it would be php based and very simple. No streams or auto encoding or anything like that.

  • Fuel does this in quite simple way: ViewModel is just an overlay. It creates single view and if you set variable on ViewModel it's set on the view. Good for taking logic out of the controller, but it's not as good as your ViewModel - there is no method 'sharing' between ViewModel and View.

  • You can actually extend the current view class into a ViewModel class with like 5-10 extra lines. I might hack it up on my way home and post it.

  • looking forward - I was about to port Fuel version, but maybe this won't be needed :)

  • Here's something I just hacked up: https://gist.github.com/1981603

    Just extend the View class, and set the _file var in it to point at your template.

    You can then access methods in the view from the template via $this->foobar. This would call the view's public function foobar() method.

  • quick'n'dirty https://github.com/thejw23/simple_vm just for taking some logic out of controller.

  • Questions regarding best/common practice:

    Do most of you guys use the layout class in KOstache or include the header, footer and any other layout related elements on each page template as partials?

    What about page specific css and js? Like if a particular page on your website requires some lines of js code in the onload event handler which is in the layout template (eg: to load a slideshow jquery plugin that's only needed on the about page). Is it best to use an array variable in the layout view class and then push data into it from it's child view classes?

    Eg: templates/layout.mustache

    $(window).load(function(){
       //page specific jquery plugin code here
    });
    

    This is sorta off topic. Sorry, I couldn't help myself since KOstache and View Models were brought up here - I began to wonder what you pros do for this sorta stuff.

  • I wonder how pros deal with this: http://forum.kohanaframework.org/discussion/comment/70650#Comment_70650 Where this kind of stuff belongs to.

  • @zombor I would actually vote for Kostache to be included into core. I think it's everything Kohana stands for. Clean, neat and following the correct programming conventions.

  • What happened to the DOT_NOTATION pragma?

  • It's built into mustache now, iirc.

  • I would actually vote for Kostache to be included into core. I think it's everything Kohana stands for.

    Unfortunately it would alienate too many users, I think.

  • For me, ViewModel is the right thing to be in the core. KOStache is to much.

  • Or it could be added as a core module along with the View. Just like database or the session modules

  • @zombor

    It's built into mustache now, iirc.

    Tried to use the dot notation, but no luck. I think it was rather removed :)

  • Just like database or the session modules

    Sessions are a core part of Kohana.

    IMO for 3.4 it would be really nice to see a simple View_Model make its way into the core. I would probably stray from including Kostache as a core module.

  • I know git can do it - but a "Kohana Builder" would be nice; to just download the core and modules you select; with a section for "unofficial" but supported" modules such as Kostache, Email, et.al.

  • [edit] I just read about Packagist on the PSR-0 thread

  • @nickg @shadowhand already made one of those. It's on github.

  • @zombor We could include mustache with the core modules and keep the current standard view implementation into Kohana. I think everyone that is using View Models are using Kostache but that is of course an assumption.

  • I think Kostache must be included in Kohana core, I totally agree with @rjd22.

  • I disagree... every one of you doesn't care for "view_model" but a specialized implementation of the concept; be it mustache or whatever else so including it is just kohana showing it's biased towards one implementation. What's the point? You have it in a nice module already, and it's not like when you update your submodules for the project mustache being part of the core or in it's own module makes any difference whatsoever. You shouldn't even notice.

    In the end kohana is suppose to be a framework not a library nor a content management system. This is why the pagination and auth module didn't make much sense either. It's essentially suppose to be boilerplate code not a standard on how to write your views.

    Well, as long as I don't have to rewrite the entire view system and have to deal with view_model nonsense on error pages, or profile pages etc (ie. nothing within kohana uses it!), I think all of us that don't like it don't really care if it's in or not.

  • @Akki

    I disagree... every one of you doesn't care for "view_model" but a specialized implementation of the concept; be it mustache or whatever else so including it is just kohana showing it's biased towards one implementation. What's the point?

    The point is that it works.

    We shouldn't be stuck on rigid principles when we develop. I think if a code is nicely structured, well documented and doesn't break anything it should be used, even if it doesn't follow strict standards that may not even were invented for the web context.

    In the end kohana is suppose to be a framework not a library nor a content management system.

    I agree with you on this, kostache shouldn't be in the core as much as in a module as it is now.

  • The point is that it works.

    Yeah but... so does everything else.

    We shouldn't be stuck on rigid principles when we develop.

    From my POV kohana adopting kostache as a core functionality is just that: funneling people into a rigid principle.

    I agree with you on this

    Err... but that means you agree with me on everything else there. :)

    (well whatever, this is probably another one of my miscommunication disasters; I knew it had to happen at some point this week)

  • @Akki Not exactly, you were hinting that people should use principles blindly, without modifying it to their own needs if necessary. For ex. if an adapted version of the view model principle is better to use in the context of Kohana than using the principle as is, then why not adapt it?

    And yes everything else works too, but that pretty much depends on context too. Sure, a procedural code is perfectly fine in the context of a CRON job for ex. This is the exact case with view models, mvc, oop, and everything else.

  • disagree... every one of you doesn't care for "view_model" but a specialized implementation of the concept;

    The whole framework is "specialized implementation" of things. That's the point. The current view implementation "locks you into it's implementation".

    This is a bad argument.

  • Replacing a View with a View_Model is a lot less trouble then the other way around. An implementation that's simpler and closer to the abstract notion is more usable then an implementation that's very elaborate and specific to some kind of pattern, because you can always build on the simple implementation but with patterns you have to break them. It's like with class inheritance: it's a lot harder to extend a class and deny part of it's functionality, then it is to make a more specialized class from a "basic" class.

    But you're right, it is in the end just another specialized implementation...

  • My two cents.

    I like the idea of adding more abilities into the Kohana core. Personally though it is my humble option though the MVVM architecture was designed for event driven interfaces, something that does not lend itself very well to server side scripting. I prefer to use Model-View-Presenter in Kohana and then use MVVM(via KnockoutJS) on the client side instead.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion