|flash messages vs. notification system||Lukas Kahwe Smith||1/6/12 1:50 AM|
If I read yesterday's logs right then the main issue with https://github.com/symfony/symfony/pull/2853 is the changes to the flash system.
Now first up if there is already agreement on the rest of the PR, then it might be worthwhile to unbundle the flash changes as much as possible from this PR to get at least the session changes in there. However that then raises the question if only the message stack changes should be removed or if also the option to clear on read should be removed.
Now to address the area where there is disagreement. What Drak has done and what many are asking for is to expand the flash message system to become a generic notification system and to see flash messages just as one use case of such a notification system.
One thing which I understand we all agreed on is that such messages should be possible to be displayed inside a layout template. So the messages themselves need to contain all information necessary to display them. Meaning the CSS class to use should be possible to be deduced from the message key for example. Furthermore it cannot be unclear of the message still needs to be translated or not etc.
Some use cases:
Use case 1) is supported with the current approach, use case 2) needs some additional code, but can also be managed by the current approach. 3) requires a notification system where messages are stacked by type.
Now we have a few options:
I personally think that C) is the right way to go. Anyone using drak's approach will simply need to adapt their layout to handle getting back an array with a single value instead of just a scalar.
|Re: [symfony-devs] flash messages vs. notification system||Luis Cordova||1/6/12 4:31 AM|
|Re: [symfony-devs] flash messages vs. notification system||Drak||1/7/12 1:11 AM|
I had a good think about this and I have to say after I took a look again, you see like me, that flashes are already a notification system. One of the concerns voiced on IRC was if allowing multiple messages per flash type woudl allow the flash system to be used in unintended ways.
After looking closely, it seems clear it's not about whether flashes are stored in a array or string that allows someone to use flashes in a different way than intended (as a notification after a form submission) because, if someone wants to use flashes for something other than a form response they already can with Symfony 2.0.x.
The display of flashes is entirely down to the layout templates so there is nothing to stop someone, for example, adding to their theme/header templates for example that looks for $name = security-warning and displays it (a use case quoted by Lukas). Flash can always be set from some other part of the application outside of the main controller. Whether you can store multiple flashes or not really doesn't matter in this case and storing flashes in a string does not stop this use-case as it stands in Symfony 2.0.x.
I'm not going to particularly lobby for "multiple flashes per type" over the current "single flash per type", but just want to be clear, looking at it you can see it really makes no difference to how flashes to how flashes can be used in a different way to their original purpose: to notify the result of a form submission. How flashes are used is entirely down to how and when you chose you display them in your application, not down to the API functions/behaviour. Allowing multiple flashes per type therefor does not, in my opinion distract the API any more than it is already.
Anyway, just some insight. I'd really like to know how to proceed. If flashes have to remain as a single string per type then ok - certainly looking at other frameworks like cake, yii and so forth, they also adopt the single string per type approach (except for Zend which has multiple messages, but not by type), but maybe this is where Symfony2 could offer some more advantages over them ;-)
Lukas Kahwe Smith
|Re: flash messages vs. notification system||Jasper N. Brouwer||1/24/12 1:48 PM|
Coming from Zend_Framework, I wasn't content with their approach, so I
built the following setup:
I have a Message containing a "template", an optional translator and
additional arbitrary properties. It implements ArrayAccess to make the
properties easily accessible.
It also implements __toString in order to render the message. When
rendering the "template" will be translated if wished, and afterwards
any %property% notations will be replaced with the value of that
I also have a MessageList, it contains Messages ;) It extends
ArrayObject for easy usage.
Messages are added with a method add( string $template, string $type,
array $properties ), which forces a Message to have a type. Internally
this type is just another property.
There are methods like hasProperty( string|array $property, mixed
$value = null ), getByProperty( string|array $property, mixed $value =
null ), clearByProperty( string|array $property, mixed $value = null )
and more... When passed only (a) property/ies it will filter Messages
containing that/ose property/ies whatever the value might be. When
passed (a) property/ies and (a) value(s) it will also match the
value(s) of that/ose property/ies.
And this is the real strength of this message system. You can easily
filter and order by type, but also by any other property. Some
examples are dividing the messages by type to display them in a box
with an appropriate color. Or include form-names in order to render
validation-messages next to the input-field they address. Or if you
divided a form into several sections, group and display the messages
above each section. You can also remove or replace messages based on
some property. Or easily alter a property before rendering.
I've developed the Message and MessageList about 2 years ago, and are
still happily using them now :)