| # |
Jun 20th 2019, 20:04 |
 ricksaccous |
I think it's because I'm not using the OrmPolicy but the mapper policy which runs in the middleware before the controller is hit |
| # |
Jun 20th 2019, 19:59 |
ricksaccous |
is not stopping the policy from happening |
| # |
Jun 20th 2019, 19:59 |
ricksaccous |
my skipAuthorization method from my component |
| # |
Jun 20th 2019, 19:59 |
ricksaccous |
hmmm |
| # |
Jun 20th 2019, 19:53 |
ricksaccous |
actually i think i'll be fine pushing them back to their dashboard |
| # |
Jun 20th 2019, 19:52 |
ricksaccous |
i suppose i'll just have to write a handle that extends redirect |
| # |
Jun 20th 2019, 19:41 |
ricksaccous |
hmm |
| # |
Jun 20th 2019, 19:41 |
ricksaccous |
there must be an easy way to redirect to referer |
| # |
Jun 20th 2019, 19:40 |
ricksaccous |
https://book.cakephp.org/authorization/1.1/en/middleware.html#handling-unauthorized-requests |
| # |
Jun 20th 2019, 18:06 |
mdotobie |
gotcha. well this actually might be a better way to do this |
| # |
Jun 20th 2019, 18:05 |
admad |
Webservice is akin to db connection and Driver is akin to pdo driver |
| # |
Jun 20th 2019, 18:04 |
admad |
Endpoint is akin to Table and Resource is akin to Entity |
| # |
Jun 20th 2019, 18:02 |
mdotobie |
Any insight on the difference between Endpoint and Resource? |
| # |
Jun 20th 2019, 18:00 |
admad |
Endpoint is your model abstraction. You would create a driver which reads the json file instead of making a GET request |
| # |
Jun 20th 2019, 17:59 |
mdotobie |
The other thing I would have wanted to add @admad would be a way to define the schema of the loaded data for validation purposes (since it’s handwritten). But I really liked the _transformResults method it has for parsing the JSON, however, I’m basically using `JsonConfig` through the `Configure` class to perform the same function. |
| # |
Jun 20th 2019, 17:57 |
mdotobie |
@admad on this particular use the JSON is written by hand in advance it isn’t coming from a service. But I was thinking about how I could extend it in the future. I did come across Webservice when I was researching if what I was trying to do was possible and how would I architect it. My only question was around whether an “endpoint” could be a file or was a URL you’re only option. |
| # |
Jun 20th 2019, 17:52 |
admad |
@mdotobie if you are fetching data from an external API is suggest you checkout muffin/webservice |
| # |
Jun 20th 2019, 17:48 |
mdotobie |
I think a really good way I intend to extend this is for caching JSON data from sources. Then the cached JSON can be read in as config data and can be updated on a schedule or on demand. But it doesn’t need to be retrieved fresh on each request because it won’t change often. |
| # |
Jun 20th 2019, 17:46 |
mdotobie |
I think I like this architecture. |
| # |
Jun 20th 2019, 17:46 |
slackebot1 |
`\App\Model\Table` namespace as `ShippingItemTable`. Instead of extending `\Cake\ORM\Table` like a normal Table, it extends `App\Model\Datasource\Json`. In turn, the Entity is in the `\App\Model\Entity` namespace as `ShippingItem` |
| # |
Jun 20th 2019, 17:46 |
mdotobie |
Hey @jeremyharris, although I know I haven’t provided alot of context, I wanted to point out that as I sat here working on this I’ve decided to move the `\App\Model\Json\Json` to `App\Model\Datasource\Json`. My first experimental subclasses of this is a definition JSON file for Shipping Carrier data, the data lives in `config` and the “table” originally lived in the `\App\Model\Json` namespace as `ShippingJson` but it’s now mixed |
| # |
Jun 20th 2019, 16:27 |
jeremyharris |
same! |
| # |
Jun 20th 2019, 16:26 |
mdotobie |
okay. sometimes I like to do a sanity check to see if the way I’m thinking about things actually makes sense. I’m prone to over-engineering…but I like the mental stretching it gives to learn how to approach problems in non-obvious ways. |
| # |
Jun 20th 2019, 16:26 |
jeremyharris |
no need to make the developer learn their API if they don’t have good typehinted clients |
| # |
Jun 20th 2019, 16:25 |
jeremyharris |
yeah in those cases it makes sense to me to wrap them |
| # |
Jun 20th 2019, 16:25 |
jeremyharris |
if you need that level of abstraction then that’s fine. Sometimes it’s not necessary, because in reality your application is tied to those APIs even after the abstraction. I guess it depends on what the service class is doing |
| # |
Jun 20th 2019, 16:25 |
mdotobie |
Well, when that API doesn’t have a straightforward API. For instance I use the Mandrill PHP library as is, but I do a lot of custom stuff to Slack so I have a SlackService class that uses the Slack API directly through Guzzle injected into the Service class. |
| # |
Jun 20th 2019, 16:23 |
mdotobie |
I actually do something I refer to as Service classes as wrappers to API libraries. |
| # |
Jun 20th 2019, 16:22 |
slackebot1 |
“importers” and the `Hash` class as the data extractor. |
| # |
Jun 20th 2019, 16:22 |
mdotobie |
That’s what I thought @jeremyharris and I figured the reason was because of what you outlined. So I think my approach of creating two new kinds of classes that mimic the Table/Entity structure without relying on the underlying datasource is the easiest way to implement what I’m after. If I was using an API as the datasource I’d probably just replace using `JsonConfig` with something like `Guzzle` as they are just intended to be the da |
| # |
Jun 20th 2019, 16:19 |
slackebot1 |
is really good. I think you *could* still write something similar that would fit within the cake 3 ORM, but it would be pretty time consuming and the ORM method support would be minimal, so it probably wouldn’t be too useful |
| # |
Jun 20th 2019, 16:19 |
jeremyharris |
I think you’re correct. That way of writing datasources for APIs has been superseded by better API clients that have their own set of exception handling for specific API errors. I wrote maybe the first Stripe plugin that was a cakephp datasource for 2.x that translated the datasource commands, like ->read, into the appropriate REST call. However, this isn’t really useful anymore because the stripe client was released some time after |
| # |
Jun 20th 2019, 16:13 |
slackebot1 |
DB data source would have worked. I like that approach as well but it seems with the changes to the ORM in Cake3, this isn’t really a path that can be taken any longer. Am I misreading that? |
| # |
Jun 20th 2019, 16:13 |
slackebot1 |
the `Table` class. The returned JSON is then loaded into a `JsonObject` that mimics the `Entity` class functionality. This `JsonObject` and/or it’s subclasses include the methods that act on the JSON data. This feels like a good approach but I was interested in any feedback. I did read an article under the CakePHP 2.0 book about leveraging the Datasource class to load data from an external API source and have it work with the Table classes in a way |
| # |
Jun 20th 2019, 16:13 |
mdotobie |
Partially to satisfy a use case and partially as an experiment, I’ve been creating a way to use a JSON file as a datasource (mostly as a way to more quickly iterate over an evolving data structure). I’ve created a class called `Json` in the Model folder that uses a combination of the JsonConfig and Hash classes to load a JSON file that is defined in a more specific subclass that extends the `Json` class. This structure is intended to mi |
| # |
Jun 20th 2019, 15:56 |
neon1024 |
..and you’ll need cascadeCallbacks set to true in your associations |
| # |
Jun 20th 2019, 15:55 |
neon1024 |
You won’t be able to cascade soft-delete without the behaviour attached to the Tables if I remember |
| # |
Jun 20th 2019, 15:55 |
peppejaripappalardo |
thx for your hint @neon1024 |
| # |
Jun 20th 2019, 15:55 |
peppejaripappalardo |
yes, the problem is that, at this time the Behavior on Events and Mission is not implemented yet. So maybe that let fail the query |
| # |
Jun 20th 2019, 15:54 |
neon1024 |
If they were cascade soft-deleted then the query shouldn’t fail |
| # |
Jun 20th 2019, 15:52 |
peppejaripappalardo |
Yes, i need to keep Missions and Events for Historical Archive |