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
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
> 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:
>> 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 Goldsmith
>> 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 Goldsmith
>>>> PHPTAL mailing list
>>> PHPTAL mailing list
>> PHPTAL mailing list
> PHPTAL mailing list
PHPTAL mailing list