Nihal Sahu asked on Twitter, “How do you ‘personally’ go about building an application? What Structure?” This post is my longer-than-140-characters response.

Obviously I’m a fan of Action-Domain-Responder as a pattern for web-based user interfaces. (ADR treats the request/response cycle itself as a user interface. The html/CSS/JS/etc that goes into the HTTP body is just one part of the presentation half of the user interface; ADR reminds us that the HTTP headers are part of the presentation, too.)

But ADR, and MVC, and the other user-interface patterns – they are not an application architecture in and of themselves. The “Domain” in ADR and the “Model” in MVC are just entry points into the underlying core of the overall application architecture. In a way, the “Action/Responder” and “Controller/View” portions of the UI are not the big deal in the application; the big deal is the underlying core. That’s where the real work happens.

With that in mind, one first thinks the right approach would be to separate the User Interface from the Core Application. This is obvious and uncontroversial; separation of concerns is a central tenet of good architecture.

What might be controversial is my extended advice regarding that approach. I don’t suggest a merely “logical” separation of concerns so that Action/Controller classes don’t have Domain/Model code in them. I suggest a “physical” separation. In other words:

Separate the User Interface repository from the Core Application repository.

Yes, I mean that you should have two code repositories for your application. Let’s explore that idea for a minute.

The first repository, the Core Application one, contains no user-interface code at all. No HTTP, no standard input/output, nothing. It expects to receive input in an interface-independent way, and it delivers output in an interface-independent way. Note that it receives the input. It has to be sent to the Core Application in some way, not read from the interface (no superglobals!). The injected input could be via method parameters, a plain old PHP array, an input object provided by the Core Application, a Command object provided by the Core application, etc. Likewise, the output could be via anything provided by the Core Application, such as a Model object, a Domain Payload, or something else. It is completely independent from any user interface code and can be tested on its own.

The other repository, the User Interface one, contains your “Action/Responder” or “Controller/View” (or “Command/Stdout”) code. There is no business logic at all. All it does it reformat the user input to something the Core Application will recognize, pass it to the Core Application, and receive back some output from the Core Application, which it reformats for presentation to the user.

But if the two repositores are “physically” separated, how can the User Interface get access to the Core Application? Composer becomes your best friend in this case. In the User Interface codebase, add "require": { "project-name/core-application": "dev-develop" } to composer.json. Issue composer update and voila: your Core Application is now available to the User Interface. The User Interface depends on the Core Applicatiion, but the Core Application has no dependency on the User Interface.

What’s great about keeping the repositories fully separated from each other is that it enforces developer discipline. It becomes difficult to put Core Application code in the User Interface code. Any attempts to do so are immediately obvious, and everyone watching can see it happening. It becomes harder to justify to yourself “I’ll add it just this one time” (and thus keeping off that particular slippery slope).

The tradeoff is that you now have to coordinate changes across two code repos. Breaks in the Core Application will break the User Interface. The disconnection can be a positive overall, since you can version the Core Application separately from the User Interface, but in practice it does mean you have to be more attentive to change management.

One more thing about keeping the User Interface “physically” separate from the User Interface in this way is that you start thinking differently about frameworks. I have begun to think that our vocabulary for describing frameworks in PHP land is insufficiently varied. MVC and ADR do not describe “application frameworks” – they might describe User Interface frameworks, but there’s no word for Core Application frameworks. Maybe they need their own separate framework term.

Xdebug 2.3: Improvements to Tracing

London, UK

Tuesday, March 31st 2015, 09:12 BST

This is the fifth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

In this instalment we are going to have a look at the additions to the trace file functionality. Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit).

Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting. Existing options are 1/2 for just the variable type, 3 for a string description, and 4 for a string description and a variable name. Xdebug 2.3 now also features a base64 encoded serialized representation of the variable's contents (option 5). Which means that the following lines:

This is probably more useful with the computerized trace files that are easier to parse.

In Xdebug 2.3, normal (human readable) trace files now also show the time index and memory usage for function exit lines. Function exit lines are generated when xdebug.collect_return is set to 1. Which means that with with Xdebug 2.2 you would see:

Show Notes

]]>Welcoming New Authors: January – March 2015SitePoint PHPhttp://www.sitepoint.com/?p=1015482015-03-30T16:00:00Z2015-03-30T16:00:00Z

With a new schedule and regime, we changed the author introduction post to a once per three months frequency rather than every other month like it was. As March is drawing to an end (already?!), let’s see which new souls joined us in this era of peer review. We’ll also use this opportunity to mention our newest regular authors.

Regular Authors

We’ve seen an influx of increased enthusiasm from our most prolific members. The first two who get to pin this medal to their chest are as follows:

Younes has been with us for a while, and has been aiming for the regular author position since Q3 2014. When a man knows what he wants, there’s little that will stand in his way, and Younes grabbed the opportunity by the throat. In 2014, he was one of our most prolific authors and in 2015 he only increased his output, always keeping quality and interesting topics in mind. I take great pride in being able to welcome him into the regulars circle, and I feel like he’s just getting started.

So far (in 2015), Younes published a whopping six posts and two quick tips. Keep up the great work!

Danny has been our Drupal expert since the day he joined. If anything was going on in the Drupal world we should know about, he was right on top of it, keeping everyone up to date and preparing the readership for Drupal 8’s imminent release. Danny earned his “R” badge in March, and starting with April, he’ll be a part of the regular circle.

Danny’s contributions not only to our Drupal corprus but also to the peer review process have been invaluable. He reviewed countless articles, shot pull requests left and right, and even made important suggestions for improving the entire workflow.

One month ago, we started the annual SitePoint framework popularity survey. Now that the month has expired, it’s time to look at the results and to distribute the prizes. The response was a whopping ~7800 entries, far more than any other survey we’ve held so far, and even after filtering out invalid entries we end up with a formidable number of valid participants.

First things first, as promised, here is the entire result set for your perusal: download. Do with it as you please - if you come up with some interesting graphs, please do share them with us! Read the “Data” paragraph below for some more details on the downloadable files.

The Most Popular Framework of 2015

Framework Winner

To view the full screen versions of all plots below, just click on them. They open in new tabs.

When you add tags to a Post and the save the Post, everything is great. But when you add posts to a Tag and then save the Tag, the posts are not saved. Why? Because Doctrine persists changes only on the owning side of a relation. The owning side is the one that has the inversedBy.

How to fix this? Simple. If you’re accessing the Entity directly (without a Symfony form), then there is only 1 step.

1. On the inverse side (Tag), you will need to edit the following methods: addPost and removePost.

This will keep the owning side in sync, so that persisting either the Post or the Tag will save the association. At this point, you can go ahead and clean up the cascade in the Tag entity, as it’s no longer necessary.

@ORM\ManyToMany(targetEntity="Post", mappedBy="tags")

2. If you’re using a Symfony form with a collection field to associate the posts, you need to add an extra option in your form builder:

->add('posts', 'collection', array(
'by_reference' => false,
//...
))

This is only needed in the Tag form (the inverse side of the relationship). If you omit this option, it will default to true and will set posts by reference. It will go fetch the ArrayCollection of posts and manipulate it directly, therefore not calling addPost/removePost that you need to keep things in sync. Setting this option to false will force the form to call these methods.