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

Xavier Perseguers typo3 at perseguers.ch
Sun Aug 23 21:03:55 CEST 2009


Hi Ingo,

>> 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 

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?

> 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.

As you may know, I started doing tests to create ExtJS backend modules. 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. 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?

> 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, 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. 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.

> 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? Perhaps I want to define 
my own template where messages are shown in a sidebar. 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.

> 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.

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, ...). You want Flash messages to become the de facto, great! I'd love to have this too but then you need to accomodate 
most if not all "common" situations and allow non-common situation (which ExtJS are certainly _not_) to tackle with Flash messages too.

Last word, I agree with Rupert that 2 UPDATE that do nothing for each page/part refresh is certainly not optimal, even if it comes from FLOW3. FLOW3 is not yet really used and v5 does not exist. The 
real "base" is Extbase, not FLOW3 and Extbase, as it is being more and more used for "real" already made enhancements which were backported to FLOW3. Ideas are really great in FLOW3 but it does not 
mean all concepts are ready to be used as-this. This is no argument to rely on how FLOW3 does something. The concepts there are much more than what we will ever (hopefully) see in v4.

Regards

-- 
Xavier Perseguers
http://xavier.perseguers.ch/en

One contribution a day keeps the fork away


More information about the TYPO3-team-core mailing list