# [RFC] New .phpp File Type for Pure-Code PHP Scripts - Thread: https://externals.io/message/59807 - Original archive: https://news-web.php.net/php.internals/59807 - Started by Kris Craig on 2012-04-12T23:03:35+00:00 - Messages: 58 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/59807.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59807 — Kris Craig — 2012-04-12T23:03:35+00:00 URL: https://externals.io/message/59807#59807 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 --Kris --- ## #59809 — Yasuo Ohgaki — 2012-04-12T23:38:21+00:00 URL: https://externals.io/message/59807#59809 · In reply to: #59807 Hi, 2012/4/13 Kris Craig : > 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 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 yohgaki@ohgaki.net --- ## #59810 — Arvids Godjuks — 2012-04-12T23:44:16+00:00 URL: https://externals.io/message/59807#59810 · In reply to: #59809 So ok, i write my code in files without extension, what happens? As it was said before, interpreter will not distinguish by the file extension, ever. It is os dependant and so on. Why are you poluting the mailing list with things that are clearly said will never happen? --- ## #59811 — David Muir — 2012-04-12T23:46:11+00:00 URL: https://externals.io/message/59807#59811 · In reply to: #59809 > Hi, > > 2012/4/13 Kris Craig : > > […] > This may work for LFI issue for new codes. > Few questions. > > CLI may use .phpp as PHP script always. (i.e. execute w/o 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? > > > […] > 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 > yohgaki@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. David --- ## #59812 — Kris Craig — 2012-04-12T23:57:13+00:00 URL: https://externals.io/message/59807#59812 · In reply to: #59809 > Hi, > > 2012/4/13 Kris Craig : > > […] > > This may work for LFI issue for new codes. > Few questions. > > CLI may use .phpp as PHP script always. (i.e. execute w/o 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? > I'm not sure what the best SAPI configuration would be, but if I had to throw out an educated guess, I'd say the .phpp extension would just go through a separate handler. All the code in the file would then be parsed as PHP, with the added error conditions as described in the RFC. So I don't anticipate there being any problems once the webserver has been configured to recognize the new file extension. The files can be included or accessed directly via HTTP (though in most cases I wouldn't recommend that from an architectural standpoint, AJAX notwithstanding of course). > > > […] > `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. > Though not necessarily required, my thinking is that that should be ok, so long as the webserver is configured to know what to do with it of course. It's conceivable that certain AJAX calls might want to take advantage of pure scripts, for example. > I cannot tell if this setting is going to be popular, but if it > does, isn't it the end of embedded PHP? > I see no reason why it should be. Embedded PHP will still be there exactly as it is now; the .php file extension will not be changed by this RFC whatsoever. As far as whether people will continue using embedded PHP, I have no idea and I'm guessing there'd probably strong opinions on both sides of that. This RFC doesn't attempt to address that question, though. The future of embedded PHP is a separate topic entirely. But my gut feeling is, so long as there are developers who continue to want it, it'll still be there for them. It might be good if PHP is more tolerant for this usage. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net --- ## #59813 — Kris Craig — 2012-04-13T00:01:37+00:00 URL: https://externals.io/message/59807#59813 · In reply to: #59810 On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks wrote: > So ok, i write my code in files without extension, what happens? > > As it was said before, interpreter will not distinguish by the file > extension, ever. It is os dependant and so on. > > Why are you poluting the mailing list with things that are clearly said > will never happen? > You might want to consider using less inflammatory, disrespectful language if you want people to respond favorably to your questions. I.e. accusing someone of "poluting [sic] the mailing list" because they posted an idea you don't like is neither constructive nor necessary. That being said, the .php file extension is not, as far as I know, determined by the operating system. It's determined by the webserver configuration. So if you have two different extensions, each with a separate SAPI handler to differentiate between them, there's no reason why this wouldn't work just fine. After all, the internet didn't explode when we dropped the .php3 extension. ;P --- ## #59816 — Yasuo Ohgaki — 2012-04-13T00:02:24+00:00 URL: https://externals.io/message/59807#59816 · In reply to: #59810 Hi, 2012/4/13 Arvids Godjuks : > So ok, i write my code in files without extension, what happens? > > As it was said before, interpreter will not distinguish by the file > extension, ever. It is os dependant and so on. > > Why are you poluting the mailing list with things that are clearly said will > never happen? There aren't any clean solution for script only PHP (yet) There are 3 methods proposed so far. - php.ini setting that controls embedded-mode https://wiki.php.net/rfc/nophptags - include/require that loads non-embedded mode https://wiki.php.net/rfc/source_files_without_opening_tag - file extension that switch to non-embedded mode https://wiki.php.net/rfc/phpp All of these have pros and cons. I prefer mine, but I'll vote +1 for any if one of these will be accepted. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59817 — Kris Craig — 2012-04-13T00:04:01+00:00 URL: https://externals.io/message/59807#59817 · In reply to: #59811 > > > […] > `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. > > […] > > 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. > > David --- ## #59821 — Arvids Godjuks — 2012-04-13T00:26:16+00:00 URL: https://externals.io/message/59807#59821 · In reply to: #59813 Well, I just don't know how i can appeal to common sence to some people on the list anymore. First the type hinting threads, now this. The world does not work only on one web server and there are different type ls of them out there. I for once use nginx and i configure how to run scripts by locations, not by file types. I just pass the params to fastcgi server thet runs a php binary. And it does not.care about the extension. I can use any extension.l for my code. Yes, i use .php, others use. phtml or other variants. Extensions are just a convension, nothing more. You can give a file any or none extension at all and it will not change a thing.Ok, in windows you will not be able to open the file in a program by double click, but through the open dialog in the app - be my guest. To PHP, fastcgi and the web server it does not matter. It just matters to people so they can distingush between a php file, js file and a css file. 13.04.2012 2:01 пользователь "Kris Craig" написал: > > > On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks wrote: > > > […] > You might want to consider using less inflammatory, disrespectful language > if you want people to respond favorably to your questions. I.e. accusing > someone of "poluting [sic] the mailing list" because they posted an idea > you don't like is neither constructive nor necessary. > > That being said, the .php file extension is not, as far as I know, > determined by the operating system. It's determined by the webserver > configuration. So if you have two different extensions, each with a > separate SAPI handler to differentiate between them, there's no reason why > this wouldn't work just fine. After all, the internet didn't explode when > we dropped the .php3 extension. ;P --- ## #59822 — Arvids Godjuks — 2012-04-13T00:29:31+00:00 URL: https://externals.io/message/59807#59822 · In reply to: #59817 Sorry, but how will i load a template then? I do that in a controller whose file is.plain php code with no html. Now i'm forced to use some kind of template engine that does not including a template, but parsing it and replacing keywords with data? I really do not have to put a sarcastic phrase here, do i? 13.04.2012 2:05 пользователь "Kris Craig" написал: > > > > […] > else) > > […] > frameworks? > > […] > > 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. > > > > […] --- ## #59823 — David Muir — 2012-04-13T00:46:47+00:00 URL: https://externals.io/message/59807#59823 · In reply to: #59817 > > > On Thu, Apr 12, 2012 at 4:46 PM, David Muir > wrote: > > > > […] > >: > > […] > proposal > > […] > tag-less PHP > > […] > or else) > > […] > locate > > […] > frameworks? > > […] > 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. > > […] > > 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 --- ## #59828 — Kris Craig — 2012-04-13T01:00:13+00:00 URL: https://externals.io/message/59807#59828 · In reply to: #59821 On Thu, Apr 12, 2012 at 5:26 PM, Arvids Godjuks wrote: > Well, I just don't know how i can appeal to common sence to some people on > the list anymore. First the type hinting threads, now this. > With all due respect, Arvids, get over it. People are going to propose ideas you don't like. I'm going to propose ideas you don't like. You can either handle it like a mature adult or you can alienate the very people you're trying to persuade. I've seen a disturbing pattern of hostile behavior bordering on abusiveness from you on a number of threads and I would ask you to take a deep breath and tone it down. If you don't think you can post a response without engaging in personal attacks and hyperbole, walk away and come back to it later when you've had a chance to get the initial emotion out of your system. Spraying the list with insults whenever someone disagrees with you is not an acceptable way of working with others IMHO. So please try to work on that. > The world does not work only on one web server and there are different > type ls of them out there. I for once use nginx and i configure how to run > scripts by locations, not by file types. I just pass the params to fastcgi > server thet runs a php binary. And it does not.care about the extension. I > can use any extension.l for my code. Yes, i use .php, others use. phtml or > other variants. Extensions are just a convension, nothing more. You can > give a file any or none extension at all and it will not change a thing.Ok, > in windows you will not be able to open the file in a program by double > click, but through the open dialog in the app - be my guest. To PHP, > fastcgi and the web server it does not matter. It just matters to people so > they can distingush between a php file, js file and a css file. > I'd prefer to avoid getting into a heated argument over something that amounts to little more than semantics. Yes, file extensions are a convention by their very nature. And yes, there would need to be some changes in order to add support for a second parsing type. But you'll notice that's why I listed the target PHP version as 6.0. A major release such as that is where one would expect these sorts of fundamental improvements to be made, plus it gives us a long time to sort out the technical details since 6.0 won't be coming for at least another few years. --Kris 13.04.2012 2:01 пользователь "Kris Craig" написал: > > > > […] --- ## #59829 — Yasuo Ohgaki — 2012-04-13T01:03:12+00:00 URL: https://externals.io/message/59807#59829 · In reply to: #59807 Hi, If we aren't going to consider saving current code risk, then we could use both new include and file name convention. Introduce application/x-httpd-php-script, then we could AddHandler php5-script .php AddType text/html .php AddType application/x-httpd-php-source .phps AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript whatever extension here We may need ENV vars for other SAPIs. script/script_once for PHP only script includes. How about this? -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59830 — Kris Craig — 2012-04-13T01:03:56+00:00 URL: https://externals.io/message/59807#59830 · In reply to: #59823 > > > > > > > > […] > > 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 --- ## #59832 — Kris Craig — 2012-04-13T01:10:20+00:00 URL: https://externals.io/message/59807#59832 · In reply to: #59829 > Hi, > > If we aren't going to consider saving current code risk, then > we could use both new include and file name convention. > > Introduce application/x-httpd-php-script, then we could > > AddHandler php5-script .php > AddType text/html .php > AddType application/x-httpd-php-source .phps > AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript > whatever extension here > Yeah that's more or less what I had in mind, actually. There'd be work involved, no question, but there's no reason why it shouldn't be doable. > > We may need ENV vars for other SAPIs. > I'm only familiar with installing PHP on Apache and IIS, so I honestly have no idea how it would work with other webservers. I'd wager that it's possible enough, but as for the "how," I'll have to defer to those who have experience working with said webserver(s). > > script/script_once for PHP only script includes. > Would the new "script" keyword behave like include or require? I'm very wary of the idea of having a special include to treat .php files the same as .phpp files, simply because it would seem to add a lot of complexity and potential for confusion, but I won't necessarily rule it out altogether, either. Right now I'm just working on reassuring those who are afraid this will cause every single framework on the internet to spontaneously combust lol. > > How about this? > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net --- ## #59833 — Yasuo Ohgaki — 2012-04-13T01:10:32+00:00 URL: https://externals.io/message/59807#59833 · In reply to: #59829 2012/4/13 Yasuo Ohgaki : > Hi, > > If we aren't going to consider saving current code risk, then > we could use both new include and file name convention. > > Introduce application/x-httpd-php-script, then we could > > AddHandler php5-script .php > AddType text/html .php > AddType application/x-httpd-php-source .phps > AddType application/x-httpd-php-script   .ph // .phpp .phpc .phpscript > whatever extension here > > We may need ENV vars for other SAPIs. > > script/script_once for PHP only script includes. > > How about this? Forgot to mention CLI. CLI switch for script only should be included. Putting all 3 RFC together may work as long as basic semantics is the same. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59834 — Yasuo Ohgaki — 2012-04-13T01:22:07+00:00 URL: https://externals.io/message/59807#59834 · In reply to: #59832 Hi, 2012/4/13 Kris Craig : > > > > > […] > > > Yeah that's more or less what I had in mind, actually.  There'd be work > involved, no question, but there's no reason why it shouldn't be doable. > > > […] > > > I'm only familiar with installing PHP on Apache and IIS, so I honestly have > no idea how it would work with other webservers.  I'd wager that it's > possible enough, but as for the "how," I'll have to defer to those who have > experience working with said webserver(s). > > > […] > > > Would the new "script" keyword behave like include or require?  I'm very > wary of the idea of having a special include to treat .php files the same as > .phpp files, simply because it would seem to add a lot of complexity and > potential for confusion, but I won't necessarily rule it out altogether, > either.  Right now I'm just working on reassuring those who are afraid this > will cause every single framework on the internet to spontaneously combust > lol. Will it? As I wrote in other thread, it convenient for backward compatibility. function script($file) { return include($file); } function script_once($file) { return include_once($file); } It's for new PHP. Why not new keyword. It's true that people are used file extension convention. application/x-httpd-php-script and script/script_once for script only PHP may confuse people. I think it is acceptable, but others may not. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59836 — Arvids Godjuks — 2012-04-13T01:26:10+00:00 URL: https://externals.io/message/59807#59836 · In reply to: #59830 Well, i can say that any template engine that is not a pure php extension does template inclusion via an include of a file with html and embedded php code. Because to make things fast you have to convert your templates from tags and pseudo code to that state and cache the result so not to make parsing on every request. And right now there is a standard for autoloading the libraries and frameworks that most big players agreed on, that will make loading of 3rd party stuff easy. Untill one converts to pphp and other does not. Autoloadijg will just break because of mixed approaches. Hm, you wrote that you have configured php only with IIS and Apache (any *nix expirience?). Try nginx, see for yourself how different it is. 13.04.2012 3:05 пользователь "Kris Craig" написал: > > > > […] > wrote: > > […] > proposal > > […] > else) > > […] > frameworks? > > […] > ignored. > > […] > RFC. > > […] > your > > […] > put > > […] > architecture. > > […] > kind > > […] > some > > […] > executed. > > […] > > 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 --- ## #59837 — David Muir — 2012-04-13T01:35:08+00:00 URL: https://externals.io/message/59807#59837 · In reply to: #59830 > > > On Thu, Apr 12, 2012 at 5:46 PM, David Muir > wrote: > > > > […] > > 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 --- ## #59839 — Yasuo Ohgaki — 2012-04-13T01:37:39+00:00 URL: https://externals.io/message/59807#59839 · In reply to: #59836 2012/4/13 Arvids Godjuks : > Well, i can say that any template engine that is not a pure php extension > does template inclusion via an include of a file with html and embedded php > code. Because to make things fast you have to convert your templates from > tags and pseudo code to that state and cache the result so not to make > parsing on every request. > > And right now there is a standard for autoloading the libraries and > frameworks that most big players agreed on, that will make loading of 3rd > party stuff easy. Untill one converts to pphp and other does not. > Autoloadijg will just break because of mixed approaches. Good point. Although there may be name conflicts, script/script_once would be better and has more compatibility. Let just make types of include decided how it behave. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net > > Hm, you wrote that you have configured php only with IIS and Apache (any > *nix expirience?). Try nginx, see for yourself how different it is. > > 13.04.2012 3:05 пользователь "Kris Craig" написал: > > > […] --- ## #59841 — Kris Craig — 2012-04-13T01:46:28+00:00 URL: https://externals.io/message/59807#59841 · In reply to: #59836 On Thu, Apr 12, 2012 at 6:26 PM, Arvids Godjuks wrote: > Well, i can say that any template engine that is not a pure php extension > does template inclusion via an include of a file with html and embedded php > code. Because to make things fast you have to convert your templates from > tags and pseudo code to that state and cache the result so not to make > parsing on every request. > > And right now there is a standard for autoloading the libraries and > frameworks that most big players agreed on, that will make loading of 3rd > party stuff easy. Untill one converts to pphp and other does not. > Autoloadijg will just break because of mixed approaches. > The autoloading standard is still more or less in its infancy IMHO; the MVC standard, on the other hand, has been around for awhile and is widely accepted. I haven't done any detailed work with the autoloading standard, but I'll look into it. I can't imagine though that it would be so inflexible as to make it completely incompatible with existing MVC standards. If that was the case, then I can't imagine ever wanting to use that, anyway. > Hm, you wrote that you have configured php only with IIS and Apache (any > *nix expirience?). Try nginx, see for yourself how different it is. > You are aware that Apache runs on both Windows and Linux, right? It's the "A" in "LAMP", after all. ;P > 13.04.2012 3:05 пользователь "Kris Craig" написал: > > > > […] --- ## #59842 — Kris Craig — 2012-04-13T01:49:08+00:00 URL: https://externals.io/message/59807#59842 · In reply to: #59837 > > > > > > > > […] > > 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 --- ## #59847 — Tom Boutell — 2012-04-13T02:38:27+00:00 URL: https://externals.io/message/59807#59847 · In reply to: #59839 The meaning is unclear, and it doesn't let you specify error reporting. Sent from my iPhone > 2012/4/13 Arvids Godjuks : > > […] > > Good point. > > Although there may be name conflicts, script/script_once would > be better and has more compatibility. Let just make types of > include decided how it behave. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > > […] --- ## #59849 — John LeSueur — 2012-04-13T03:24:40+00:00 URL: https://externals.io/message/59807#59849 > > > On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur wrote: > > > […] I missed replying to the list here, sorry! > John LeSueur wrote: > > […] > 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: //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. > > > > […] > > 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. John --- ## #59852 — Kris Craig — 2012-04-13T05:13:34+00:00 URL: https://externals.io/message/59807#59852 · In reply to: #59849 On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur wrote: > > > > > […] > I missed replying to the list here, sorry! > > > > […] > > 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. > > > > […] > > > […] > > 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: render( "MyTemplate" ); controller.class.php: 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 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 --- Next page: https://externals.io/message/59807.md?page=2