I think copy&paste of whole getFunctionName is fine. 

I'm not sure whether it's responsibility of sources to compute the hash. 

You could however create and set your own template repository class that 
returns sources that use fake paths. 

Compile ahead of time is a good use-case. That's something that PHPTAL could 
support "natively". 

-- 
regards, Kornel


On 15 sie 2012, at 17:26, Robert Goldsmith <rgoldsm...@names.co.uk> wrote:

> 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

_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to