On Sun, Apr 15, 2012 at 3:58 AM, David Muir <davidkm...@gmail.com> wrote:
> On 14/04/12 03:41, Kris Craig wrote: > > > > On Thu, Apr 12, 2012 at 11:37 PM, David Muir <davidkm...@gmail.com> wrote: > >> On 13/04/12 15:13, Kris Craig wrote: >> > Again, the controller should NOT be a .phpp file. Likewise, your model >> > should NOT be hooking directly to the view. The controller hooks to the >> > model. The controller then sanitizes that and returns it to the view. >> > Alternatively, if you're not conforming to a pure MVC standard, the >> > controller can also hook to a regular .php file in the model and pass >> the >> > data to that. Either way, it all passes through the controller. The >> model >> > and view should never be interacting directly. MVC or not, that's just >> bad >> > architecture and there are zero advantages to using such an ad hoc >> approach. >> > >> > If a developer insists on using such a broken model, however, they're >> more >> >> MVC is a broken model/bad architecture? >> > > Arrooo? Not sure where you got *that* from, as it's basically the exact > opposite of what I said.... > > > > That was me being snarky. I understood what you were trying to say, but > you were trumpeting the superiority of MVC, while deriding architecture > that conforms to common MVC patterns. > > > >> > than welcome to! That's what people love (and hate) about PHP. It's >> > flexible. They just won't be able to use a .phpp file upstream from >> that, >> > as it is by its very nature inherently incompatible with such a broken >> > model. The only way to force it to be compatible would be to make the >> > .phpp file essentially meaningless. >> > >> > So if you're writing good code structure, a .phpp file will help you >> make >> > it even better. If you're writing bad architecture, then just keep >> doing >> > what you're already doing and don't worry about using a .phpp file! >> This >> > will in no way stop you from being able to do what you can already do in >> > PHP. You're just insisting on wanting to use a pure code file for >> > something that it's not intended to be used for. Just like having >> object >> > orientation added in PHP 5 didn't stop you from writing procedural code >> if >> > you want to, introducing this in PHP 6 won't stop you from writing >> > disorganized code if you still want to. What this will do is provide a >> > valuable option for people who do feel that writing clean, >> role-segregated >> > code is important. >> >> So basically, the only parts that might be ok to write as .phpp are some >> model and utility classes? >> > > Essentially, yes. Despite your implication, often times these components > make up the vast majority of a modern PHP application. > > > It's also the portion that is typically not provided by frameworks and > libraries. If you're extending or implementing anything from those > libraries, and they're provided as .php (as most things would be), then you > won't be able to use them in your .phpp classes (unless you explicitly > include them from a .php file further up the chain). You end up losing a > lot of flexibility, with no perceivable gain. > The gain has been described by myself and others quite a bit already. As far as I can tell, the fact that some frameworks/libraries wouldn't be compatible with this doesn't negate the unrelated advantages that do exist. Worst-case scenario, you just wouldn't use this with those frameworks. But again, before we jump down that rabbit hole again, please refer to recent suggestions that have been made regarding that; i.e. a third type for per-file instead of per-stack checking. While I see no more value in per-file checking than you do in per-stack, it would alleviate your concerns regarding certain frameworks and libraries. --Kris > > Cheers, > David >
