We actually have 5 template directories so it is easiest to keep the cache dir separate. It also keeps the live environment similar to the dev environment so easier for debugging etc.
However, even just subclassing getFunctionName is a problem because we actually need to change a couple of lines of code in the middle of the function. The only way to do this is to copy/paste the whole function and make the changes we need. The function calls 2 private functions in the parent class so unless I change those to be protected instead of private the code won't run (not allowed to call the parent private functions from within the subclass). While this is a bit of a hack it is something I'm willing to support for the moment. What I'd really like to do, however, is move the calculation of the hash or, possibly just the path used within the hash, into the Source classes so anyone wishing to provide a new Source would be able to control this. The timestamp method is already called on the Source. It might be possible to modify getRealPath() in a Source instead but a scan through the code suggests this is used in a number of places both for finding the original templates and generating the hashes. Obviously if you feel I could change this to a 'fake' path without breaking anything then I can use this instead :D In case anyone is wondering why I'm going to this effort, we are looking to deploy our live code in a signed, read only Phar. We want to modify the live environment so that the only php allowed to execute is within a signed Phar in order to add a strong new layer to our site security. Robert ----- Robert Goldsmith rgoldsm...@names.co.uk On 15 Aug 2012, at 17:11, Kornel Lesi??ski <kor...@geekhood.net> wrote: > I don't understand why do you need to patch anything else other than > getFunctionName and cleanUpGarbage. > > Change those two and configure temp dir to be your template dir. Unless you > want temp dir for phptal:cache separate from template dir? > > -- > regards, Kornel > > > On 15 sie 2012, at 15:56, Robert Goldsmith <rgoldsm...@names.co.uk> wrote: > >> The private methods used in the PHPTAL class effectively prevent subclassing >> to extend / replace the hashing. I can see your argument because the PHPTAL >> class is still very 'generic' and large despite all the work to have support >> classes and subclassing it could cause problems in future releases. >> Personally, however, I'd consider that as a problem for the developers >> wishing to subclass, not a problem for you :) >> >> For the moment, I'm just going to have to patch the 4 private methods to >> change them to protected but this is obviously not a great solution. >> >> May I suggest as a future enhancement that an additional method be added to >> the Source interface that compliments 'getRealPath()' specifically for use >> in generating the hash so the Source classes can be subclassed instead of >> the PHPTAL class? >> >> Robert >> ----- >> Robert Goldsmith >> rgoldsm...@names.co.uk >> >> >> >> >> On 15 Aug 2012, at 15:41, Kornel Lesi??ski <kor...@geekhood.net> wrote: >> >>> The fact there are protected methods is historical. >>> >>> There can be interactions between base class and subclasses via overridden >>> protected methods, so protected methods are de-facto a public interface. >>> >>> Subclassing may cause Fragile Base Class Problem (the non-C++ kind), so I >>> prefer to mark all methods private unless I explicitly intended them to be >>> overridden, thought through interdependencies and committed to not changing >>> them. >>> >>> -- >>> regards, Kornel >>> >>> >>> On 15 sie 2012, at 14:56, Robert Goldsmith <rgoldsm...@names.co.uk> wrote: >>> >>>> Hello :) >>>> >>>> Thanks for those pointers :D I'm also going to override prepare() to throw >>>> an exception if the template needs parsing because this won't be allowed >>>> on a live system. >>>> >>>> One thing I have noticed, however, is that 4 functions in the PHPTAL class >>>> are private rather than protected: >>>> getPreFiltersCacheId() >>>> getPreFilterInstances() >>>> setCodeFile() >>>> getFunctionNamePrefix() >>>> >>>> Is there a specific reason for this or is it just historical? Obviously it >>>> is much harder to subclass a class with private methods. >>>> >>>> Robert >>>> ----- >>>> Robert Goldsmith >>>> rgoldsm...@names.co.uk >>>> >>>> >>>> >>>> >>>> On 15 Aug 2012, at 14:08, Kornel Lesi??ski <kor...@geekhood.net> wrote: >>>> >>>>> The hash is computed in PHPTAL::getFunctionName(). Filename is built from >>>>> that name. >>>>> >>>>> Subclass PHPTAL class and override this method to compute unique name >>>>> from path/settings you care about. >>>>> >>>>> Also override cleanUpGarbage() to stop it from deleting compiled >>>>> templates. >>>>> >>>>> -- >>>>> regards, Kornel >>>>> >>>>> >>>>> On 15 sie 2012, at 09:59, Robert Goldsmith <rgoldsm...@names.co.uk> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We're implementing a deployment system using phars and pre-compiled >>>>>> templates from phptal and things are mostly going well but we've noticed >>>>>> that the template file hashes appear to be based on the full path of the >>>>>> template when it is initially compiled. Obviously if we then move the >>>>>> templates (put them in a phar and drop them on a different server) this >>>>>> isn't going to work. >>>>>> >>>>>> Has anyone attempted to change the way the template name hashes are >>>>>> calculated before and can they give me some pointers as to the way to go >>>>>> about doing it? >>>>>> >>>>>> Robert >>>>>> ----- >>>>>> Robert Goldsmith >>>>>> rgoldsm...@names.co.uk >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> PHPTAL mailing list >>>>>> PHPTAL@lists.motion-twin.com >>>>>> http://lists.motion-twin.com/mailman/listinfo/phptal >>>>> >>>>> _______________________________________________ >>>>> PHPTAL mailing list >>>>> PHPTAL@lists.motion-twin.com >>>>> http://lists.motion-twin.com/mailman/listinfo/phptal >>>> >>>> >>>> _______________________________________________ >>>> PHPTAL mailing list >>>> PHPTAL@lists.motion-twin.com >>>> http://lists.motion-twin.com/mailman/listinfo/phptal >>> >>> _______________________________________________ >>> PHPTAL mailing list >>> PHPTAL@lists.motion-twin.com >>> http://lists.motion-twin.com/mailman/listinfo/phptal >> >> >> _______________________________________________ >> PHPTAL mailing list >> PHPTAL@lists.motion-twin.com >> http://lists.motion-twin.com/mailman/listinfo/phptal > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal _______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
