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

[Ingo Renner]

Xavier Perseguers wrote:

Hi Xavier,

> Do you know of a single case where this was done? Lots of stuff are done
> "in case of..." but is there anyone who know of who created own
> dedicated templates for BE?

I know some agencies that do that (having their own BE skin), so the 
str_replace() would be in the interest of backwards compatibility.

> As you may know, I started doing tests to create ExtJS backend modules.

Why should I know about everything? Only god might. :)

> I do not rely anymore on any template, meaning I'll (and I guess *I*
> won't be the only one) need a way to show these messages without refresh
> of the whole page.

if you're not using the standard way (in the sense of being proposed by 
the core API documentation or being generated by the kickstarter) I feel 
it's your own duty to take care of being compatible. After all we can't 
take care of all possible cases, even though we try to not break things 
with existing stuff.

> A few extensions are now using ExtJS even without
> what I'm planning to do. See EXT:addresses for instance. How are Flash
> messages supposed to work for those modules? Or are Flash messages only
> meant for Core extensions? Will recycler be able to show those Flash
> messages?

You'd have to call the new methods in class template yourself I guess or 
check the BE user's session.
Another approach would be to check with JS for the existence of a 
message, "cut it out" and display it wherever you need it.
So in general it's not imposible, you just have to take care yourself 
when not using standard ways of doing stuff, but that's the case with 
other things in the core as well.


>> 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.
>
> That's a problem since 4.2 IIRC,

That's right, so it's time to finally fix it.

> before it just worked well, the
> docheader was simply a bit further away but a scrollbar allowed us to
> show it as well as the module content itself and we all were happy.

Might be that you were happy, but I doubt you know about all the user 
out there. At least from an agency dedicated to usability I work with 
from time to time I heard that they appreciate the fixed docheader a lot.

> Since the change, debugging in BE is a pain, and Flash messages might
> help a bit but won't certainly allow us (again) to debug using
> t3lib_div::debug() calls.

Why shouldn't that be possible? It's just a matter of redirecting that 
output into flash messages (or at least the same area), too.

>> 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.
>
> You said earlier that you did not change the template as there might be
> cases were it was updated. Well, then why do you force those Flash
> messages to be shown before content?

Uhm, because that's where they belong? Because everyone else does it 
that way and I don't want to reinvent the wheel?

> Perhaps I want to define my own
> template where messages are shown in a sidebar.

"Perhaps", that's the same "in case of..." nature you critized yourself, 
right? So feel free to change that once you have a scenario where really 
need taht.

> It won't be possible if
> you str_replace() the content, by updating the template itself as Rupert
> suggested, you allow us to put it wherever it makes much sense.

Well again, by doing it through str_replace() we make sure that even 
people which changed the skin will see important messages, especially 
those regarding security. In this case I rate this interest higher than 
flexibility, won't you agree?


>> 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.
>
> It's mainly a way to ease the task of committing this patch but it
> certainly is not anything else than that. By modifying the template you
> allow anybody to put it where it makes sense in any situation and by
> modifying the main template (which I guess nobody ever change), you can
> ensure too that it is put before content.

I'm afraid, but I have to disagree. Please see my points above, I hope 
they're reeasonable.

> And again for ExtJS modules, we'll have to have a way to get those Flash
> message asynchronously without relying on any page refresh and allowing
> us to change the way they are displayed or where and how they are
> displayed (in a sliding panel, in a popup message, in a taskbar, ...).

As mentioned above, it's possible to do so.


all the best
Ingo

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