On Thu, Apr 12, 2012 at 6:26 PM, Arvids Godjuks <arvids.godj...@gmail.com>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" <kris.cr...@gmail.com> написал: > > 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 >> >
