[TYPO3-core] RFC #11684: Add support for flash messages in the backend

[Ingo Renner]

Rupert Germann wrote:

Hi Rupi,

> we have already some "messaging systems" in the TYPO3 Backend:

The flash messages are supposed to generalize and unify all these 
messages in one consistent look and feel. A RFC doing this will follow 
after this one's in.

> 1. tcemain printLogErrorMessages()
> which collects its messages in the syslog table

How do I trigger this one?

> 2. t3lib_BEfunc::isRecordLocked()
> which displays the "locked" icons and the beautyful yellow warning box
> on top of editforms.
>
> 3. t3lib_BEfunc::displayWarningMessages()
> used in alt_intro

Especially these two are supposed to be replaced by flash messages.

> Id'd like to see an approch to substitute existing things, which are
> sometimes more complicated than needed or redundant, by better ways to
> do the same.

Exactly, I think the flash message class is a quite simple thing to use.

> now some details:
> I don't like the fact that each call to popFlashMessages() (= almost
> each click) triggers an UPDATE query, no matter if there's something to
> update or not.

That part has been taken from FLOW3, I'll take a look at it.

> If I click on web->list this function is called even 2 times (= 2
> unneeded queries) because the navframe is reloaded too.

Well, this happens with everything upon changing a submodule of Web, right?

 > is the navframe supposed to display error messages?

However, you're right that only the right frame should display the 
messages. But then again that should be the case automatically as the 
messages are created, displayed, and immidiatly removed afterwards.

> at least in the current implementation both frames will display the same
> messages, which doesn't make much sense.

So, could you explain what you did to make the messages show up in both 
frames?
It could make sense though to display messages that are directly related 
to the tree only. I can't think of a scenario for that though.

> I also don't like this line:
>
> $moduleBody = str_replace('###CONTENT###', $flashMessages .
> '###CONTENT###', $moduleBody);
>
> We have templates and markers in backend modules, so please use a
> dedicated marker for the messages instead of str_replacing it in the
> template.

You're right, but it's done that way on purpose: In case someone 
modifies or uses a different template, the current implementation 
ensures that the flash messages are shown in either case. Markers can 
not be forgotten, put in a wrong place, or left out on purpose as the 
message to show might be important. The str_replace() way also ensures 
that the messages are shown before the actual content and that they're 
shown in extension modules.
AFAIR the current version of the kickstarter would also not create a 
dedicated marker for the flash messages. This is not an issue as that 
can be adjusted. But by using the str_replace() method flash messages 
also work with existing modules without having to modify them.

There's also another issue flash messages are going to be used: 
Currently, when there's a notice, warning, or exception during the 
execution of a module, those errors are printed at the beginning of the 
module, atop the docheader and pushing the topheader down in a way that 
it might be impossible to hit the save button or anything else in the 
docheader.
The solution to this is to introduce an error and exception handling 
system that collects all errors and also uses flash messages to show 
them in a non-disruptive way atop of the content, not pushing down 
controls in the docheader. Str_replace again makes sure that the errors 
are displayed at the right location and make sure that they're definitly 
shown.

Hope that clarifies why I chose str_replace(), it's mainly a way to 
enforce displaying the messages and making sure to have them displayed 
at the right place.


all the best
Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2