Skip to content
This repository has been archived by the owner on Nov 30, 2022. It is now read-only.

Extending base shop model vs moving functions to a trait #137

Closed
awebartisan opened this issue Nov 7, 2018 · 17 comments
Closed

Extending base shop model vs moving functions to a trait #137

awebartisan opened this issue Nov 7, 2018 · 17 comments
Assignees
Labels
feature Enhancement to the code

Comments

@awebartisan
Copy link
Contributor

Hi,
I am using this package and extending the BaseShop, I need to use another package which requires model to extend their base class too. How we are going to deal with such situation? Can we move the code in Shop.php model of this package to a trait?

Please have a look into it. thank you 👍

@gnikyt
Copy link
Owner

gnikyt commented Nov 7, 2018

I can move the code to a trait yes and leave the default model still there including the trait for backwards compatibility.

@gnikyt gnikyt self-assigned this Nov 7, 2018
@gnikyt gnikyt added feature Enhancement to the code fix-in-progress In progress labels Nov 7, 2018
@awebartisan
Copy link
Contributor Author

So if someone use only trait, what will happen to ShopObserver? I can change to the model to \App\Shop in the config. ShopObserver will not fire and it will cause trouble. What are your thoughts on this one?

@gnikyt
Copy link
Owner

gnikyt commented Nov 7, 2018 via email

@awebartisan
Copy link
Contributor Author

use OhMyBrew\ShopifyApp\Models\Shop;
Observer has this use statement on its top and it uses this in creating function. I have tried moving all the code from BaseShop model of package and moved to my own Shop model and removed extends keyword then i faced ShopObserver problem.

@gnikyt
Copy link
Owner

gnikyt commented Nov 7, 2018 via email

@awebartisan
Copy link
Contributor Author

        $shopModel = config('shopify-app.shop_model');
        $shopModel::observe(ShopObserver::class);

Yes they did this in ShopifyAppProvider.php , but ShopObserver.php class still uses package base model in use statement and creating function.

@gnikyt
Copy link
Owner

gnikyt commented Nov 7, 2018 via email

@gnikyt
Copy link
Owner

gnikyt commented Nov 8, 2018

It turns out this may not be possible.

I can not have $fillable, $casts, $dates, etc properties inside the trait. Because the base Eloquent defines them, the trait can not override it. Moving the properties and defining them inside the constructor of the model does not work, I get "fillable" errors on a few tests.

There does not seem to be a work around for this unfortunately. Only work around I see is to define all methods in the trait, and keep the properties inside the model class.

This is not ideal, but it would mean if you use the trait directly (without extending the shop model), you would need to also manually add the properties to your own class to ensure it works.

On the fence about this one...


Example of above (not working, cant work):

class ShopModel extends BaseModel {
    use ShopModelTrait;
}

Example of above (which could work), but I'm not sure its a clean way...

class ShopModel extends BaseModel {
   /* define properties here for $fillable, etc */

  use ShopModelTrait;
}

// Your own model...
class MyOwnShopModel {
  /* define the same properties */

 use ShopModelTrait;
}

This is an issue because if the core properties of a model changes (additions, deletions, changes), then your own model would fail without updating it, which could lead to issues, but of course, I could just doucment this in the changelogs if such a change should happen.

@awebartisan
Copy link
Contributor Author

I am also searching, will let you know if I get some idea from anywhere. Looking at other packages specifically which require extending their models for overriding methods and properties.

@awebartisan
Copy link
Contributor Author

https://gist.github.com/JordanDalton/f952b053ef188e8750177bf0260ce166

you probably stumbled upon this also?

@gnikyt
Copy link
Owner

gnikyt commented Nov 9, 2018

I have but this involves overwriting how eloquent does fillables and such. Which would depend on me updating the code should that change. Doesn't seem like a clean solution can happen besides the one I mentioned above which is still not totally clean but at least helps anyone wanting to extend

@awebartisan
Copy link
Contributor Author

awebartisan commented Nov 9, 2018

Okay... can you add the trait including only functions and mention in documentation to use it on your own risk? and add the properties to your own model which will be using the trait.

@gnikyt
Copy link
Owner

gnikyt commented Nov 13, 2018

Yup that should work

@awebartisan
Copy link
Contributor Author

Any timeline about this feature?

@awebartisan
Copy link
Contributor Author

https://www.archybold.com/blog/post/booting-eloquent-model-traits

Does this help in any way to solve above problem?

@gnikyt
Copy link
Owner

gnikyt commented Nov 15, 2018

Sadly the above still causes complaints by Eloquent, it just wont work nicely.

I've gone the trait + model for properties. Its now available through v4.2.0 release. All tests passed, code coverage remained at 100.

See the wiki article on override and extending for more information; essentially use the trait and paste in the same properties from the base model.

@gnikyt gnikyt added status-resolved and removed fix-in-progress In progress labels Nov 15, 2018
@gnikyt gnikyt closed this as completed Nov 15, 2018
@gnikyt
Copy link
Owner

gnikyt commented Nov 15, 2018 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature Enhancement to the code
Projects
None yet
Development

No branches or pull requests

2 participants