Add some feedback when performing some actions #552

trinity-1686a · 2019-04-27T16:06:51Z

elegaanz 已留言

2019-04-27 16:06:51 +00:00

(已從 github.com 遷移)

Here is an example of what it looks like (this is just a test, in reality you can only have one of these messages at the same time):

I don't know if there is a simpler way to do it. Also, I added msg: Option<FlashMessage> to almost all routes to be sure that if a message was present it would be rendered, but maybe it is not necessary and only make the code harder to read? And maybe msg should go in PlumeRocket as it is used almost everywhere?

Fixes #468

Here is an example of what it looks like (this is just a test, in reality you can only have one of these messages at the same time): ![Screenshot_2019-04-27 Plume unu ⋅ Plume](https://user-images.githubusercontent.com/16254623/56852089-77178700-690e-11e9-88fc-acb089b58fef.png) I don't know if there is a simpler way to do it. Also, I added `msg: Option<FlashMessage>` to almost all routes to be sure that if a message was present it would be rendered, but maybe it is not necessary and only make the code harder to read? And maybe `msg` should go in `PlumeRocket` as it is used almost everywhere? Fixes #468

👍 1

codecov[bot] 已留言

2019-04-27 16:13:23 +00:00

(已從 github.com 遷移)

Codecov Report

Merging #552 into master will increase coverage by 0.02%.
The diff coverage is 5.12%.

@@            Coverage Diff             @@
##           master     #552      +/-   ##
==========================================
+ Coverage   44.08%   44.11%   +0.02%     
==========================================
  Files          68       68              
  Lines        7937     7984      +47     
==========================================
+ Hits         3499     3522      +23     
- Misses       4438     4462      +24

# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/552?src=pr&el=h1) Report > Merging [#552](https://codecov.io/gh/Plume-org/Plume/pull/552?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/787eb7f3992e43e7a149288f3378c90dd4fe4bf8?src=pr&el=desc) will **increase** coverage by `0.02%`. > The diff coverage is `5.12%`. ```diff @@ Coverage Diff @@ ## master #552 +/- ## ========================================== + Coverage 44.08% 44.11% +0.02% ========================================== Files 68 68 Lines 7937 7984 +47 ========================================== + Hits 3499 3522 +23 - Misses 4438 4462 +24 ```

trinity-1686a 已留言

2019-04-28 18:43:40 +00:00

所有者

And maybe msg should go in PlumeRocket as it is used almost everywhere?

Considering how it must be everywhere, I think it can go in PlumeRocket, as well as in template BaseContext. Also BaseContext could implement From<PlumeRocket> so it is easier to build and reduce duplication

> And maybe `msg` should go in `PlumeRocket` as it is used almost everywhere? Considering how it must be everywhere, I think it can go in `PlumeRocket`, as well as in template `BaseContext`. Also `BaseContext` could implement `From<PlumeRocket>` so it is easier to build and reduce duplication

👍 1 🚀 1

igalic (已從 github.com 遷移) 已審核 2019-04-29 06:58:41 +00:00

igalic (已從 github.com 遷移) 留下了回應

maybe we should hold on committing the translations in such prs?

do then regularly elsewhere

maybe we should hold on committing the translations in such prs? do then regularly elsewhere

po/plume/hr.po

igalic (已從 github.com 遷移) 已留言

2019-04-29 06:54:07 +00:00

this is supposed to be

Ti nisi autor ovog(a?) bloga

but i just realised that fuzzy means it was auto translated…

this is supposed to be > Ti nisi autor ovog(a?) bloga but i just realised that fuzzy means it was auto translated…

elegaanz 已留言

2019-04-29 07:49:00 +00:00

(已從 github.com 遷移)

@igalic I don't really know… it is true it pollutes a little bit the diff, but at the same time it makes sense to have them with the change in the interface.

elegaanz (已從 github.com 遷移) 已審核 2019-04-29 07:49:27 +00:00

po/plume/hr.po

elegaanz (已從 github.com 遷移) 已留言

2019-04-29 07:49:27 +00:00

Yes, it was auto-translated. Once it will be on Crowdin, you will be able to fix it. 😉

Yes, it was auto-translated. Once it will be on Crowdin, you will be able to fix it. :wink:

trinity-1686a 已留言

2019-04-29 11:15:41 +00:00

所有者

I'd be to not pollute pr with this, and have something that autocommit the changes once a week, or after each merge

👍 1

trinity-1686a 已審核 2019-04-29 19:29:25 +00:00

trinity-1686a 留下了回應

所有者

👀

:eyes:

src/template_utils.rs

					
				@ -17,0 +27,4 @@

				        &Connection,

				        &Catalog,

				        Option<User>,

				        Option<(String, String)>,

trinity-1686a 已留言

2019-04-29 19:12:08 +00:00

所有者

why not implementing From<PlumeRocket> for Context? It will auto implement Into<Context> for PlumeRocket, and you should be able to use into() with no need to import this trait everywhere

why not implementing `From<PlumeRocket>` for Context? It will auto implement `Into<Context>` for PlumeRocket, and you should be able to use `into()` with no need to import this trait everywhere

elegaanz (已從 github.com 遷移) 已審核 2019-04-29 20:55:43 +00:00

src/template_utils.rs

					
				@ -17,0 +27,4 @@

				        &Connection,

				        &Catalog,

				        Option<User>,

				        Option<(String, String)>,

elegaanz (已從 github.com 遷移) 已留言

2019-04-29 20:55:43 +00:00

Because Rust is complaining about the fact that all the parameters of the trait comes from another crate, and that it could cause conflicts, while I don't think it can? 🤷‍♀️ But yeah, I tried it, and it doesn't work.

Because Rust is complaining about the fact that all the parameters of the trait comes from another crate, and that it could cause conflicts, while I don't think it can? :woman_shrugging: But yeah, I tried it, and it doesn't work.

trinity-1686a 已審核 2019-04-29 22:32:41 +00:00

src/template_utils.rs

					
				@ -17,0 +27,4 @@

				        &Connection,

				        &Catalog,

				        Option<User>,

				        Option<(String, String)>,

trinity-1686a 已留言

2019-04-29 22:32:41 +00:00

所有者

ho, it's because BaseContext is not a true struct but a typedef to a tuple of basic types (in theory it could cause conflict, because the exact same trait can be implemented in plume-model, thus creating a conflict). This mean we can either convert BaseContext to be a true type, or implement Into in plume-models. I've tried the first one, but it requires some small but ugly changes so I'm not sure it would be better (you can take a look at the patch here)

ho, it's because BaseContext is not a true struct but a typedef to a tuple of basic types (in theory it could cause conflict, because the exact same trait can be implemented in plume-model, thus creating a conflict). This mean we can either convert BaseContext to be a true type, or implement Into in plume-models. I've tried the first one, but it requires some small but ugly changes so I'm not sure it would be better (you can take a look at the patch [here](https://framadrop.org/r/aXcBuKkLEW#rzbPsNSdq+XCFboTnRLdY8Qt3RNqqUYGgrnA8bfUoQQ=))

trinity-1686a 核可了這些變更 2019-04-30 09:08:06 +00:00

trinity-1686a 留下了回應

所有者

👍

:+1:

elegaanz 已留言

2019-04-30 10:00:12 +00:00

(已從 github.com 遷移)

Do you want me to apply your patch before merging?

trinity-1686a 已留言

2019-04-30 10:02:26 +00:00

所有者

It was just to show what I came up with, but having &(&rockets).into() everywhere is definitely worse than importing a trait

It was just to show what I came up with, but having `&(&rockets).into()` everywhere is definitely worse than importing a trait

👍 1

登入才能加入這對話。

沒有審核者

沒有里程碑

未選擇專案

沒有負責人

2 位參與者

通知

截止日期

截止日期無效或超出範圍，請使用「yyyy-mm-dd」的格式。

未設定截止日期。

先決條件

未設定先決條件。

參考: Plume/Plume#552

列
欄