Home/ Questions/Q 9008097
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T01:51:44+00:00

Some background: I came from a .Net environment where we had to use MVVM

  • 0

Some background: I came from a .Net environment where we had to use MVVM in all of our projects to separate the view from the viewmodel. Now that I’m working on my own personal PHP project I decided to use the same design and separate the view and viewmodel.

So on the view I create a viewmodel object and call background functions when necessary and in the view the code is only to provide the display.

Example:

view.php

<?php
include('viewmodel.php');

$vm = new viewmodel.php();

if(some condition)
{
  $vm->doSomething();
}
?>
<html>
<body>
//some form code
</body>
</html>

viewmodel.php

<?php
//includes

class viewmodel
{
  function viewmodel()
  {
  }

  function doSomething()
  {
  }
}
?>

Now that I’ve learned jQuery I want to use it to make my pages more dynamic, have less traffic back and forth to the server and less need for page refreshing.

I’ve seen calls like this that allow jQuery to call a php page with some some post data:

$.ajax({ url: '/my/site',
         data: {action: 'test'},
         type: 'post',
         success: function(output) {
                      alert(output);
                  }
});

However this is no longer Object Oriented Design and I would have to remove all the class definitions from my viewmodels for this to work.

Is there any way for jQuery to make those calls to the viewmodel or does using jQuery mean you have to return to a procedural style of programming?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    However this is no longer Object Oriented Design and I would have to remove all the class definitions from my viewmodels for this to work.

    What makes you think that? There’s nothing inherently object-oriented or non-object-oriented about making AJAX requests to the server. Nor do these client-originated requests have any bearing on the architecture of the server-side code.

    In your views you can have any JavaScript code you’d like. It won’t make a difference to the server-side code rendering the view, as the JavaScript is just text as far as it’s concerned and no different than the HTML.

    As for the server-side handler, what you’ll probably want to do is create entirely new views and viewmodels for the “page” (“resource” is a more accurate word) that’s being called by the jQuery code.

    So, for example, you might get a request from the browser for something like /my/site which would, using the architecture you have in place, populate a viewmodel to bind to a view and return that view to the client. That view would contain some JavaScript code, some of which calls another resource. Let’s say that other resource is something like /api/products which returns a list of “products” available for the user.

    Note that I put the resource under a different path, api instead of my. This was a pretty arbitrary decision, and it’s only used to illustrate that what you’re returning in this case isn’t a “page” so much as it is JSON data for an automated API. The actual name of the resource can be anything you like, of course.

    This resource can still be a view and be bound to a viewmodel, but in this case the view is JSON data instead of HTML. As with anything, there are many ways you can do this. A quick Google search turned up another question which talks about the differences between a couple of methods for generating JSON data. Indeed, your “view” in this case might be entirely empty and all you’re doing is serializing a viewmodel to JSON and returning that. (My PHP is pretty rusty, but the ASP.NET MVC equivalent would be to return an ActionResult of Json() instead of View().)

    Keep in mind that, from the perspective of the server-side code, there is no difference between returning a view in HTML vs. returning one in JSON (or XML, or raw text, or anything else). A view is a view, each one independent from the others.

    • 0