[TYPO3-project-4-3] Improve performance of flashmessages

[Ernesto Baschny [cron IT]]

Hi Rupi,

thanks, nice!

I would prefer not to call it "persistent", as this is not the case. It
is session-based, which is not persistent (in the sense that it will not
be there "forever").

So maybe calling it "sessionMessage" or "inSession" might be more
appropriate (well, haven't found a nicer name...)

Cheers,
Ernesto

Rupert Germann schrieb:
> hi,
> 
> here's a patch which introduces a new optional parameter for the
> flashmessages constructor: isPersistent.
> If a flashmessage is instantiated with isPersistent set to TRUE this
> message will be stored in the be_user's session (see
> t3lib_messageQueue::addMessage()).
> if isPersistent is FALSE (default) the message will be stored in a
> static var in the messageQueue class.
> When the messages are fetched from the queue (function
> t3lib_messageQueue::getMessages()) both queues are merged together.
> 
> I think this change can go to one rfc. It makes the flashmessage
> handling faster by default and it still offers the possibility to store
> persistent messages which will survive a redirect.
> 
> does that fit?
> 
> greets
> rupert
> 
> 
> Ernesto Baschny [cron IT] schrieb:
>> Rupert Germann schrieb:
>>> Ernesto Baschny [cron IT] schrieb:
>>>> Rupert Germann schrieb:
>>>>> - I make a new RFC containing the API cleanup from this patch, but
>>>>> leaving the storage mechanism untouched
>>>> You mean having an option to keep flash messages in the session? Or an
>>>> option to have "volatile" flash messages that are not stored in the
>>>> session?
>>> For the time being I planned no configuration options - just the API
>>> cleanup. The messages will be stored in the db by the messageQueue class
>>> which uses the TYPO3 "session handling" like it is now.
>>>
>>> In a next step we could think about a new parameter for the
>>> flashmessages object which is used by the messageQueue to decide wether
>>> the message has to be stored persistent or only for one request.
>>
>> Exactly what I meant.
>>
>>> A parameter for writing them automatically to table sys_log would also
>>> be a handy option.
>>
>> Yes, that is true!
>>
>> Cheers,
>> Ernesto
>