On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur <john.lesu...@gmail.com>wrote:
> > On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig <kris.cr...@gmail.com> wrote: > >> >> >> On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur <john.lesu...@gmail.com>wrote: >> >>> >>> >>> On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig <kris.cr...@gmail.com>wrote: >>> >>>> On Thu, Apr 12, 2012 at 6:35 PM, David Muir <davidkm...@gmail.com> >>>> wrote: >>>> >>>> > On 13/04/12 11:03, Kris Craig wrote: >>>> > >>>> > >>>> > >>>> > On Thu, Apr 12, 2012 at 5:46 PM, David Muir <davidkm...@gmail.com> >>>> wrote: >>>> > >>>> >> On 13/04/12 10:04, Kris Craig wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Thu, Apr 12, 2012 at 4:46 PM, David Muir <davidkm...@gmail.com> >>>> wrote: >>>> >> >>>> >>> On 13/04/12 09:38, Yasuo Ohgaki wrote: >>>> >>> > Hi, >>>> >>> > >>>> >>> > 2012/4/13 Kris Craig <kris.cr...@gmail.com>: >>>> >>> >> Per recent discussions, I have drafted an RFC for this. This >>>> proposal >>>> >>> >> offers what I believe to be a more sane and realistic approach to >>>> >>> >> addressing the question of incorporating a new breed of tag-less >>>> PHP >>>> >>> >> scripts. >>>> >>> >> >>>> >>> >> https://wiki.php.net/rfc/phpp >>>> >>> > This may work for LFI issue for new codes. >>>> >>> > Few questions. >>>> >>> > >>>> >>> > CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or >>>> >>> else) >>>> >>> > It's like DOS, though. >>>> >>> > >>>> >>> > How do you enforce .phpp as script only for Web? >>>> >>> > Is it a rule for configuration? or .phpp just never supposed to >>>> locate >>>> >>> > under docroot? >>>> >>> > It relates previous question. How about bootstrap script for >>>> >>> frameworks? >>>> >>> > >>>> >>> >> A regular .php script cannot be included from a .phpp script. An >>>> >>> E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR >>>> will be >>>> >>> thrown for require; in both instances, the included file will be >>>> ignored. >>>> >>> > Some people may try to make .phpp handled by web. >>>> >>> > I cannot tell if this setting is going to be popular, but if it >>>> >>> > does, isn't it the end of embedded PHP? >>>> >>> > It might be good if PHP is more tolerant for this usage. >>>> >>> > >>>> >>> > Regards, >>>> >>> > >>>> >>> > -- >>>> >>> > Yasuo Ohgaki >>>> >>> > yohg...@ohgaki.net >>>> >>> > >>>> >>> >>>> >>> That's a huge WTF that a templating library can't be written as >>>> .phpp, >>>> >>> because it then won't be able to load a template. >>>> >>> >>>> >> >>>> >> That's actually not true. Please refer to the diagram embedded in >>>> the >>>> >> RFC. >>>> >> >>>> >> Basically, you can load a template just fine-- you just can't do it >>>> >> directly from a .phpp file, which you shouldn't be doing, anyway. >>>> The >>>> >> .phpp file is, at least for the most part, intended to be included >>>> from a >>>> >> regular .php file, which also would include whatever you're using >>>> for your >>>> >> templates. In other words, they can interact just fine; you just >>>> can't put >>>> >> the template upstream from a .phpp file in the include stack-- which, >>>> >> again, you really shouldn't be doing, anyway, as it's just bad >>>> architecture. >>>> >> >>>> >> >>>> >> >>>> >> How is this bad architecture? Every framework I've seen that has >>>> some >>>> >> kind of templating layer that handles the scope and inclusion of the >>>> >> template, and it happens further down the chain from the controlling >>>> code. >>>> >> >>>> >> Zend_View, Twig or Smarty would have to remain as .php and not .phpp, >>>> >> otherwise they wouldn't be able to render the templates. >>>> >> >>>> >> In the case of Zend Framwork, which I'm most familiar with, the >>>> >> application, front controller, dispatcher, and action controllers, >>>> and some >>>> >> services would have to remain as .php so that templates could be >>>> executed. >>>> >> >>>> >> Oh, and the autoloader can't be .phpp either. But then if it's .php, >>>> then >>>> >> the autoloader can't be called from .phpp files to include .php >>>> files. >>>> >> >>>> >> Cheers, >>>> >> David >>>> >> >>>> > >>>> > It's been awhile since I've used Smarty, but unless my memory is >>>> failing >>>> > me, I'm pretty sure it's not restricted to being several points >>>> removed >>>> > upstream as you described. I'm not familiar with Zend_View or Twig >>>> so I >>>> > can't comment on those. >>>> > >>>> > Thing is, there's no reason why you can't hook any framework into >>>> this. >>>> > Worst-case scenario, if the library you're hooking into has a rigid >>>> > structure, just write a simple controller class layer to operate on >>>> top of >>>> > it, then use that same controller class to interface with the .phpp >>>> stack. >>>> > Problem solved. It's really not as complicated or confusing as you're >>>> > making it out to be. >>>> > >>>> > --Kris >>>> > >>>> > >>>> > Both Smarty and Twig compile your template files down to php >>>> templates. >>>> > Zend_View, Aura.View, and Symfony's php view include php files >>>> directly >>>> > without a compilation phase. >>>> > >>>> > I don't get how I would write a "simple controller class layer to >>>> operate >>>> > on top of it". >>>> > >>>> > Does the inclusion limitation apply to just the script in question, >>>> or the >>>> > entire call stack? >>>> > >>>> > A simplified example: >>>> > index.php -> FrontController.phpp -> Controller.phpp -> View.phpp -> >>>> can't >>>> > include template.phtml >>>> > >>>> > index.php -> FrontController.phpp -> Controller.phpp -> View.php -> >>>> can >>>> > include template.phtml ? >>>> > But I can't do require_once('View.php') in the controller. >>>> > >>>> > If there's an autoloader involved, it would have to be set up in >>>> > index.php, and would also have to be .php so that it can include both >>>> file >>>> > types. >>>> > >>>> > index.php -> FrontController.phpp -> Controller.phpp -> >>>> Autoloader.php -> >>>> > can include View.php ? >>>> > >>>> > But will that work since there are .phpp files above it in the call >>>> stack? >>>> > >>>> > Cheers, >>>> > David >>>> > >>>> >>>> I'm sorry, I was vague on this point in my previous response. The >>>> controller script would be standard .php, not .phpp. And rather than a >>>> one-dimensional linear progression, there would be parallel stacks, one >>>> .php and the other .phpp, both coming together in the controller (which >>>> is >>>> .php). >>>> >>>> If I get some time this weekend I'll try to throw together a working >>>> example. Perhaps that'll help clarify my thinking on this. =) >>>> >>>> --Kris >>>> >>> > I missed replying to the list here, sorry! > > >> John LeSueur wrote: >>> I'm -1 on this, since the main benefit of .phpp is for class/library >>> files. This handles models just fine, but controllers who include .php >>> files for templating won't be able to take advantage. Also, any templating >>> library will have to be written with .php. Smarty, Twig, etc. use class >>> files just as much as any model or controller, and have just as much reason >>> to use .phpp. >>> >> Kris Craig Wrote: >> As I said, this is simply not true. Controllers that include .php files >> for templating would still be able to include .phpp files and thus take >> full advantage. Again, I would strongly encourage you to review the >> diagram posted on the RFC. >> > > But controllers can't be in a .phpp file, even when they are pure php. > Take the following: > Again, I'm not saying that they should be. The controller is a .php file, not a .phpp file. > > //a controller, maybe a class, maybe just a set of functions, but in a > .phpp file > function getLoginPage() > { > //set up some data > //some people like to use plain .php for templates > include 'templates/loginPage.php'; > //other people like to use a View library > $view->render('loginPage.tpl'); > } > > In the case of using a view object, your controller can be a .phpp file. > In the case of the include, it cannot. Now consider the case of the > implementation of the render() method: > > function render($template) > { > $compiledTemplate = $this->compile($template); > include $compiledTemplate; > } > > Now your render method cannot be in a .phpp file. > 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 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. > > >> >> >>> What exactly is the benefit of this kind of segregation? why would a >>> .phpp file care that no other files included after it are .php? >>> >> >> Simple: It's a lot easier to hire a designer and a programmer than it is >> to hire two people who are each fluent in both design and programming. In >> other words, on complex projects with intense graphical and functionality >> requirements, being able to separate the development process into design >> and scripting components, without merge conflicts between the two, is far >> more efficient and economical. That's why familiarity with the MVC >> standard is listed as a requirement on many (if not most) developer job >> postings nowadays. >> >> > >> If you have .phpp files, the designer immediately knows to steer clear. >> Likewise, it means that the PHP developer can build the model with >> impunity because he knows it won't collide with the work that the designer >> is doing on the templating layer. The controller is the point where the >> two meet, and that would be a .php file which includes both .php and .phpp >> files, thus allowing full cooperation and interaction between the two while >> simultaneously segregating their roles. >> > > Yes, the segregation provided by MVC is great. I'm not questioning that. > I'm asking about the segregation of include trees of .phpp(code) files from > include trees of .php(template) files. They're already going to be > separated in the filesystem(in any sane application), so designers won't be > looking at .phpp files(and in some cases, may not have access to that > portion of the code tree). I just don't agree that the engine also needs to > create segregated include trees in order to facilitate MVC. There's a lot > of ways to do the V in MVC, and a lot of ways to connect the C to it. It > seems like this RFC puts restrictions on those in an unnecessary way. I'm > not sure we're going to agree on this point(as you said somewhere else, > smart people disagree all the time), but I wanted to make my objections > clear. > When I say they need to be segregated, what I'm referring to is model code being separated from template code. There is never a valid reason for the two to interact directly without going through an intermediary (i.e. a controller). If your code does, ok. Using a .phpp file in that project probably wouldn't be the best option for you. Either way, your existing code will continue to work just as it does now. There's no rule saying you HAVE to convert your code to MVC, after all. This RFC merely provides support for that, which I believe is warranted given its wide usage and the significant advantages it would bring to facilitating that. Regarding your rendering example, you could make it work by simply structuring it like so: frontend.view.php: <?php require( "controller.class.php" ); $controller = new Controller(); print $controller->render( "MyTemplate" ); controller.class.php: <?php class Controller { // Constructor, methods, etc.... Pretend they're all here, including dispatch, etc. public function render( $template ) { // Insert whatever code here. // Process some variables used by the template for whatever reason. require_once( "model.class.phpp" ); $model = new Model( $whatever ); $this->templatevars = $model->calculate_quantum_particle_density( $somevar, TRUE, 42, "Alan Alda" ); // Now get the template and pass the template vars array to it. require_once( "templates.view.class.php" ); $templates = new Templates(); $html = $templates->load( $template ); return $model->parse_hypothetical_templatescript( $html, $this->templatevars ); } } I think the point has been made so I'll refrain from conjuring fake model and template scripts. As you can see, the .phpp and .php code are interacting perfectly. Of course, it obviously wouldn't make any sense to have raw HTML code in the template load function since the frontend viewer is handling that, plus I'd probably have put the variable parsing stuff in the template class as well but I put it in the model just to illustrate the point. If, for some stupid-ass reason, Templates::load() executed over a section of ?> HTML code, no error would be thrown (it would just look really, REALLY stupid lol). Why? Because the controller is a .php file, NOT a .phpp file. As such, it does exactly what a controller should do; facilitate interaction between the model and view entry points. Now, if your code has a completely incompatible architecture that has ?> stuff mixed in all over the place in the stack, then a .phpp file really isn't appropriate for that project, anyway. But if you do have a clean separation, then this will enable you to write all the scripts in your model layer in pure PHP code without having to worry about <?php tags or ?> HTML crap getting inadvertently mixed-in. If it works for you, use it. If it doesn't, just keep doing what you're doing. Make sense? --Kris P.S. Don't bother pointing out flaws in the example code I created above. It's just pseudo-code that I threw together to demonstrate how the .php and .phpp code are able to interact via the controller, nothing more. ;) > > John >
