[TYPO3-dev] date and datetime fields

[Martin Kutschker]

ries van Twisk schrieb:
> 
> On Feb 23, 2008, at 1:33 PM, Steffen Kamper wrote:
> 
>>
>> "Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> 
>> schrieb im
>> Newsbeitrag
>> news:mailman.1.1203790936.12685.typo3-dev at lists.netfielders.de...
>>>> Steffen Kamper schrieb:
>>>> how can this work? the start/stop has to be read anyway imho.
>>>
>>> Of course I wrote nonsense :-) It's the cache of pages linking to the
>>> possibly hidden page that is the problem. You would have to tune their
>>> cache time manually. The clear-at-midnight is just a simple idea to make
>>> sure that at midnight all pages are regenerated so that links to oages
>>> with start/stop may appear and disappear.
>>
>> damn, that makes it really complicate. So how to fiddle all the pages 
>> that
>> link to the appearing page? Or clear all page cache?
>>
>>>
>>>> So may be i don't know the real process with cache, is record untouched
>>>> when page is cached?
>>>> If page has a start-date, it's not displayed before, how could the page
>>>> be cached? (stop yes)
>>>
>>> See above.
>>>
>>>> Should such signal-dates processed anyway and also used for clearing 
>>>> the
>>>> cache?
>>>
>>> TYPO3 has "now" (for a couple of versions) the soft-references feature.
>>> IMHO this could be used for improved cache management. A cron job could
>>> look for pages that change state (shown/hidden) because of start/stop 
>>> and
>>> could clear the cache for all pages that link to those pages. A similiar
>>> mechanism could be used in the BE whenever a page is changed. Currently
>>> there is only the option to clear the cache of the parent and the 
>>> siblings
>>> but here again soft-refences could come into play.
>>>
>>> Masi
>>
>> sounds promising. I don't know this soft-references, where do i find 
>> this in
>> core?
>>
>> vg  Steffen
> 
> Isn't it simple possible to make a join against the pages table to check if
> a page needs to be generated or not? Not everybody can create cron jobs,
> specially on shared hosting providers.

Of course you can do the check for cache invalidation at save time as it 
is done now. But this is not possible for the cache invalidation because 
of start/stop time changes. *

Masi

* Well in theory you can do this at any time you want. Just as a login 
triggers with some probability a session expiry check, but this isn't 
really right. And unlike the session expiry the start/stop time cache 
may be an expensive operation.