See also related pull request.

Awesome! 👍

Great work! :)

What is the reason for refactoring two different functionalities in one pull?

@mishak87 you should take a breath, calm down and think before you write.

@mishak87 @rostenkowski I have already did a review, you are just copying my notes ;)

@mishak87 My goal was to separate RequestStorage and provide redirect to original URL when restoreRequest() is called. But RequestStorage has dependency to flash messages so I had to separate them too.

@fprochazka Next time write what I did wrong instead of how you think I should handle myself which is extremely rude.

@MartinMajor Such note would be very helpful in the description (削除) along with review from @hrach (削除ここまで).

As Majkl always reminds people don't force push pulls it messes up comments.

@mishak87 I think it's extremely rude to push people into doing work that is not neccesary. For example telling them to separate code to two pullrequests if it's already separated by commits.

FYI pullrequests are meant to be forcepushed in.

@fprochazka Nobody is rushing anyone. I asked a simple question and got an answer. Your little tantrums are OT.

What pull requests mean or not I do consult only The Spaghetti Monster.

I've renamed MessagesStorage -> MessageStorage and MessagesStorage::isOpended() -> MessageStorage::hasMessages()

I don't know what problem is with FLASH_KEY in IMessageStorage.
IMessageStorage stores flash messages into some storage but its key has to be transfered in URL no matter what storage is used. Other services (e.g. RequestStorage) has to be able get this key, so this constant should be IMHO in IMessageStorage.

FLASH_KEY in Presenter has to be for back compatibility.

@MartinMajor Name of the key is related to routing or presenter. Storage should not know about it.

@mishak87 And where would you put that constant? In Presenter? So all services, that need to use it (e.g. RequestStorage) had to have dependency on Presenter?

I think it is great. The only little bit confusing thing is mixing terms message vs flash.

@MartinMajor To sum it up. I think this is step forward. But there is still missing what I would call bluntly layer for embedding non presenter related parameters into url (set of interfaces or events). If you try separating flash message functionality into own package you would see the issues.

IMO flash message is Web 1.0 concept and should be done away completely. It does not help with UX issues and offers only limiting functionality to user. User can't react on it. Some Nette projects modify its behavior, because they are lazy to write its own component. Or just for translating text. Final solution should enable creation of more featured replacements. Icons, links, buttons, templating etc.

Now I think that MessageStorage is over-engeneered :-) Because it is not about "messages" and it's doubled $id in setId() and setMessage() is confusing and very closely tighted to components in presenter.

In fact, MessageStorage is just storage for any values. It can become FlashStorage, (削除) but the fact that it exists only few seconds is not its main purpose (in addition it must be set manually via setExpiration). The main purpose is to be "attached" to the single tab in browser. So it is BrowserTabStorage. (削除ここまで)

And (削除) BrowserTabStorage (削除ここまで) FlashStorage, without all "message stuff", is universal storage, so it can be implemented in nette/http and used in application this way dg@9a59074.

This pull should therefore look like dg@0147db4

Another thing: is it really needed to have REQUEST_KEY and FLASH_KEY in URL together?

@dg: ok, as I wrote above, my main goal was to refactor RequestStorage, so I have nothing against TabStorage.
REQUEST_KEY & FLASH_KEY: When request is restored (and REQUEST_KEY is used) there can be generated new flash message (e.g. "login successful") so there are both this keys in URL at the same time (if that is what have you asked for).