On 14/04/12 03:41, Kris Craig wrote: > > > On Thu, Apr 12, 2012 at 11:37 PM, David Muir <davidkm...@gmail.com > <mailto: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. Cheers, David
