Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MessagesStorage & RequestStorage #4

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

MartinMajor
Copy link

This pull request separates flash messages into new service MessagesStorage. It also separates store & restore requests into new service RequestStorage. This new service redirects to original URL when restoring old requests.

@MartinMajor
Copy link
Author

See also related pull request.

@hrach
Copy link
Contributor

hrach commented Apr 20, 2014

Awesome! 👍

* Checks if a flash session namespace exists.
* @return bool
*/
function isOpened();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK it should be isOpen()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually should be hasMessages() anything else is misleading.

@rostenkowski
Copy link

Great work! :)



/**
* Checks if a flash session namespace exists.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment assumes implementation will use session.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true and it should be changed. But storing flash messages into another storage than sessions is quite problematic, because you have to handle, that no one can see another user's messages. Sessions gives you this for free.

@mishak87
Copy link

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

@fprochazka
Copy link
Contributor

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

@hrach
Copy link
Contributor

hrach commented Apr 20, 2014

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

@MartinMajor
Copy link
Author

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

@mishak87
Copy link

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

@fprochazka
Copy link
Contributor

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

@mishak87
Copy link

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

…essageStorage service (thanks to Filip Prochazka)
…stStorage service; restoreRequest() redirects to original URL
@MartinMajor
Copy link
Author

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

@MartinMajor
Copy link
Author

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.

@mishak87
Copy link

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

@MartinMajor
Copy link
Author

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

*/
public function getMessages($id = NULL)
{
return $this->getSession()->$id;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably here should by (array)

@dg
Copy link
Member

dg commented Jun 2, 2014

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

@mishak87
Copy link

mishak87 commented Jun 2, 2014

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

@dg
Copy link
Member

dg commented Jun 3, 2014

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

@dg
Copy link
Member

dg commented Jun 3, 2014

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

@MartinMajor
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants