messages_en.json

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
I think this should be called CceAlertRepository as CammelCase requires, we have that check on the backed side but not for the UI, you can change it if you want, but it is probably fine like this, ...

I think this should be called CceAlertRepository as CammelCase requires, we have that check on the backed side but not for the UI, you can change it if you want, but it is probably fine like this, I guess that we have more of those in other files

Service is now repository impl.

Service is now repository impl.

I would like to see the UI drift to a more standardized form following v7 Architecture. In v7 Architecture service is suppose to be a application level service.

I would like to see the UI drift to a more standardized form following v7 Architecture. In v7 Architecture service is suppose to be a application level service.

Is it really necessary, especially because a CCE alert isn't really going to have any behavior on the UI? It seems like this abstraction feels a bit overengineered. I can understand it more for POD...

Is it really necessary, especially because a CCE alert isn't really going to have any behavior on the UI? It seems like this abstraction feels a bit overengineered. I can understand it more for POD, since it's a domain object.

We've dropped using these. We can just place them in the beforeEach block.

We've dropped using these. We can just place them in the beforeEach block.

We don't have to add classes if we don't have any methods on them. I'd say we remove it.

We don't have to add classes if we don't have any methods on them. I'd say we remove it.

New changes--I believe I have addressed all issues except the RepositoryImpl.

New changes--I believe I have addressed all issues except the RepositoryImpl.

OLMIS-4127 Changes after code review feedback

* CCE alert data builder

* More tests

* Move messages

  1. … 12 more files in changeset.
I think it's perfectly fine to add it so we express our desired behavior through such tests.

I think it's perfectly fine to add it so we express our desired behavior through such tests.

I'm a bit hesitant to, as with this, I know exactly what the contents of cceAlerts is. Do we find data builders for fairly simple objects to be beneficial?

I'm a bit hesitant to, as with this, I know exactly what the contents of cceAlerts is. Do we find data builders for fairly simple objects to be beneficial?

I don't know if it's necessary, as none of the params are required.

I don't know if it's necessary, as none of the params are required.

Unfortunately we have to duplicate it... https://review.openlmis.org/static/ql0uca/2static/images/wiki/icons/emoticons/sad.gif

Unfortunately we have to duplicate it...

But it's used in multiple modules?

But it's used in multiple modules?

Looks like it https://review.openlmis.org/static/ql0uca/2static/images/wiki/icons/emoticons/biggrin.gif

Looks like it

So then we do need the update after all.

So then we do need the update after all.

Chongsun Ahn https://docs.angularjs.org/api/ngResource/service/$resource#$resource-returns
No, $resource doesn't provide a standard method for PUT as far as I'm concerned.

No, $resource doesn't provide a standard method for PUT as far as I'm concerned.

What I meant is they should be tab-separated.

What I meant is they should be tab-separated.

We should drop the method part and add isArray: false.

We should drop the method part and add isArray: false.

This save is not a PUT, then?

This save is not a PUT, then?

Not sure what you mean by this statement.

Not sure what you mean by this statement.

We usually check if we're calling correct endpoints for services/repositoryImpl. I would really like us to push toward a standardized class like RESTfulRepositoryImpl, but we don't have that yet.

We usually check if we're calling correct endpoints for services/repositoryImpl. I would really like us to push toward a standardized class like RESTfulRepositoryImpl, but we don't have that yet.

So, should we drop this section, or add an "isArray: false"?

So, should we drop this section, or add an "isArray: false"?

Actually, I think we should add a separate Repository class that will serve as an abstraction layer. Similar way it works of proof of delivery.

Actually, I think we should add a separate Repository class that will serve as an abstraction layer. Similar way it works of proof of delivery.

No, sorry I thought I resolved this.

No, sorry I thought I resolved this.

What kind of tests do we want here? I skipped it, as there isn't really any logic here--it just returns whatever is the response from the backend.

What kind of tests do we want here? I skipped it, as there isn't really any logic here--it just returns whatever is the response from the backend.

Is this still the case, if factory will stay as-is? Where is another pattern in the code for a RepositoryImpl?

Is this still the case, if factory will stay as-is? Where is another pattern in the code for a RepositoryImpl?

Well they're coming from our RTM partner, so we'll need to leave it as-is.

Well they're coming from our RTM partner, so we'll need to leave it as-is.